MITRE ATT&CK T1690 Prevent Command History Logging: Detecting Control Tampering

Prevent Command History Logging (T1690) is how an intruder makes sure the shell they are typing into keeps no record of what they did, so the first responder who opens a history file finds nothing useful. ATT&CK v20 places T1690 in the Defense Impairment tactic (TA0112) on ESXi, Linux, macOS, network devices and Windows, and it replaces the older Impair Command History Logging sub-technique of the former Impair Defenses technique, which v20 shows as revoked. The technique is cheap, quiet and used by state groups and ransomware crews alike. This page covers the history mechanisms each platform uses, what real adversaries have done to them, the telemetry that survives when history does not, the v20 mitigations and how to test your coverage. It is written for detection engineers, Linux and Windows platform owners and network teams. For the tactic as a whole, see the ATT&CK Stealth and Defense Impairment Tactics Guide.

Key takeaways

• History files are a convenience, not an audit log. Bash, zsh, PSReadLine and network device CLIs record history for the user, and the user (or anyone holding their session) can switch it off with one environment variable or option.
• Detect the switch, then log around it. ATT&CK v20 detection strategy DET0563 looks for HISTFILE, HISTCONTROL and HISTFILESIZE changes on Linux, macOS and ESXi, Set-PSReadLineOption changes on Windows and commands such as no logging on network devices.
• Your real record must live elsewhere. auditd execve records, pam_tty_audit, PowerShell script block logging (event 4104) and AAA command accounting on network devices all keep working when the user's history file is disabled, and all ship off the host.
• It is used in real intrusions. v20 lists APT38, Medusa Group, Sea Turtle, UNC3886, BPFDoor, VIRTUALPITA, BRICKSTORM and the ArcaneDoor campaign among its procedure examples.
• Service and automation accounts matter too. Shells opened under service accounts, CI runners and break-glass identities often have no interactive owner watching their history, so their session telemetry needs the same central collection.

What T1690 is

ATT&CK describes T1690 as impairing command history logging to hide the commands an adversary runs. It has no sub-techniques in v20. The mechanisms differ by platform, but every one of them is controlled from inside the user's own session, which is why the technique works so reliably.

Two details catch defenders out. First, Microsoft's Set-PSReadLineOption reference lists SaveIncrementally as the default HistorySaveStyle, with SaveAtExit and SaveNothing as the alternatives, so a history file that stops growing mid-session is itself a signal. Second, PSReadLine deliberately does not save command lines containing strings such as password, asplaintext, token, apikey or secret (Microsoft's about_PSReadLine page). The very commands that handle credentials are therefore missing from history by design, even without an attacker, which is one more reason history files cannot be your evidence of record for secrets handling.

Deleting a history file after the fact is a related but separate technique, T1070.003 Clear Command History, covered under the T1070 Indicator Removal Defensive Guide. T1690 is about stopping the record being written in the first place.

How adversaries use it: real cases

ATT&CK v20 records these procedure examples, each with its cited source. Attribution here is exactly as ATT&CK states it.

Three patterns stand out. On Linux, the trick is usually a single variable change at the start of a session, often inside a dropped script. On Windows, actors such as Medusa go for the file after the fact, so the evidence you need is the PowerShell operational log, not the history file. On appliances, the target is wider than history: Cisco Talos describes Line Dancer disabling syslog and hooking crash dump generation so the device reboots without a dump, and Talos advises treating gaps in logging and unexpected reboots as suspicious. The Salt Typhoon telecom intrusions show the same habit on routers: a custom tool cleared logs while capturing traffic across chains of devices. Threat actor background is in the UNC3886 Threat Actor Profile Guide, APT38 Threat Actor Profile Guide and Medusa Ransomware Threat Actor Profile.

What to detect and where

DET0563 in ATT&CK v20 has one analytic per platform. The data components and log sources below come from that strategy; the right-hand column is NHI Mgmt Group's practical reading of each.

Telemetry that survives history tampering

• Linux execve auditing: auditd records every program execution with its arguments regardless of HISTFILE. See the Linux Logging and auditd for Defenders Guide for rule design and volume control.
• Linux TTY auditing: pam_tty_audit enables kernel TTY input auditing per user pattern, reviewed with aureport --tty. Its man page warns that auditing is inherited by child processes and recommends disable=* first for most daemons; passwords are not logged unless log_passwd is set, and even then some cases differ.
• PowerShell script block logging: event 4104 records the content of script blocks. Microsoft recommends Protected Event Logging when script block logging is used beyond diagnostics, with the decryption private key kept off the logging machines. The PowerShell Security Guide covers the policy settings.
• Process creation: Sysmon event 1 or EDR process telemetry captures command lines whether or not PSReadLine saves them. See the Sysmon Guide.
• Network device AAA accounting: TACACS+ command accounting records commands on the AAA server, off the device. Cisco's IOS Software Integrity Assurance guidance gives aaa accounting commands 15 default start-stop group tacacs+ as an example, and notes that syslog does not forward console or vty commands on its own.
• ESXi: forward shell and host logs to a remote collector so stopping vmsyslogd leaves a visible gap. See the ESXi Logs Detection Guide.

Tuning notes

Expect benign hits. Some distributions ship HISTCONTROL=ignoreboth (ATT&CK notes this), and administrators set HISTFILE=/dev/null in throwaway containers or when typing secrets. Baseline shell profiles first, then alert on changes made inside interactive or remote sessions, especially when combined with a new login source, a privilege change or a download. A missing history file on its own is weak; a missing history file plus a burst of execve records for the same session is strong.

Mitigations

ATT&CK v20 maps two mitigations to T1690:

• M1039 Environment Variable Permissions: prevent users from changing HISTCONTROL, HISTFILE and HISTFILESIZE. In practice this means setting them in a system-wide profile and marking them read-only for the shell, which raises the bar but does not stop a user who launches a shell without profiles. See M1039 Environment Variable Permissions.
• M1028 Operating System Configuration: set HISTCONTROL to ignoredups rather than ignoreboth or ignorespace. See M1028 Operating System Configuration.

NHI Mgmt Group recommends treating both as hygiene, not as the control. The control is logging that the session user cannot reach:

1. Enable execve auditing on Linux servers that accept interactive logins, and pam_tty_audit for privileged users where policy allows keystroke capture.
2. Enable PowerShell script block logging and process creation logging on all Windows servers and administrator workstations, and forward them centrally.
3. Configure AAA command accounting to an external TACACS+ server on routers, switches and firewalls, and send device logs to at least two collectors.
4. Route privileged and service-account shell access through a session-recording gateway, so the recording happens outside the target host. See the Privileged Session Management Guide if it fits your estate.
5. Alert on the logging pipeline itself: a host or device that stops sending, or a syslog daemon that stops, should page someone.

Where identity fits

Many shells on a server are not opened by a person. Deployment pipelines, configuration management agents and break-glass accounts run commands under service identities, and nobody reviews their history files. An attacker who steals a service account's SSH key or token inherits a session that is rarely watched, and disabling history there costs nothing. Tie session telemetry to the identity that opened it: log which key or token authenticated, alert when a service identity opens an interactive TTY it does not normally use, and include automation accounts in the scope of execve and script block logging. The How to Find ssh authorized keys across a server fleet guide helps you find which keys can open those sessions.

How to test

1. Linux: in a lab or pilot host, open an interactive session, unset HISTFILE, run a harmless command such as id, and confirm the execve record and the HIST* variable alert both reach the SIEM.
2. Windows: run Set-PSReadLineOption -HistorySaveStyle SaveNothing in a test session, then a benign command, and confirm event 4104 and the Sysmon event 1 arrive and your rule fires.
3. Network devices: in a change window on a lab device, remove and restore a logging host and confirm both the AAA accounting record and the collector gap alert.
4. ESXi: on a lab host, confirm that stopping log forwarding produces a gap alert within your target time.
5. Roll back: restore the shell profile or PSReadLine option and log entries for the test; document the test so analysts do not chase it.

Measure the result with a small set of numbers:

• Percentage of Linux servers with execve auditing forwarded centrally.
• Percentage of Windows hosts with script block logging (4104) arriving in the SIEM in the last 24 hours.
• Percentage of network devices with AAA command accounting to an external server.
• Mean time from a log source going silent to an alert.
• Number of DET0563-style alerts per month, and the share closed as known administrator behaviour (for tuning).

Common failure patterns

• Treating .bash_history as evidence. Incident timelines built from history files miss everything an attacker chose not to record.
• Read-only variables as the only control. M1039 is bypassed by any shell started without the profile; the authoritative record must come from the kernel or the AAA server.
• Script block logging enabled but not collected. Event 4104 that stays on the endpoint is lost when the attacker clears logs or the disk is encrypted.
• Device logging to one local buffer. A single no logging command removes the only record; Talos's ArcaneDoor guidance treats gaps in logging as a signal precisely because actors create them.
• Ignoring service account sessions. Rules scoped to named administrators miss shells opened with automation keys.

Framework mapping

Related Defense Impairment techniques, each with its own page: MITRE ATT&CK T1686 Disable or Modify System Firewall, MITRE ATT&CK T1688 Safe Mode Boot.

Practitioner checklist

• Inventory which shells and devices rely only on local history for command records.
• Enable and forward auditd execve rules on Linux servers that accept logins.
• Enable PowerShell script block logging and Sysmon or EDR process creation on Windows servers and admin workstations.
• Configure TACACS+ command accounting and at least two remote syslog targets on network devices.
• Deploy DET0563-style rules for HIST* changes, PSReadLine changes and no logging commands.
• Alert on log source silence for servers, hypervisors and network devices.
• Set HISTCONTROL=ignoredups system-wide and protect HIST* variables as hygiene.
• Include service and automation accounts in session logging scope.
• Run the test steps above each quarter and after logging changes.

Standards and references

• MITRE ATT&CK: T1690 Prevent Command History Logging
• GNU: Bash Reference Manual, Bash Variables
• Microsoft Learn: Set-PSReadLineOption
• Microsoft Learn: about_Logging_Windows
• Linux man-pages: pam_tty_audit(8)
• CISA: #StopRansomware Medusa Ransomware (AA25-071A)
• Google Cloud Threat Intelligence: Bad VIB(E)s, ESXi hypervisor malware persistence
• Cisco Talos: ArcaneDoor, espionage campaign targeting perimeter network devices

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · T1685 Disable or Modify Tools Defensive Guide · T1070 Indicator Removal Defensive Guide · Linux Logging and auditd for Defenders Guide · Network Device Syslog and Configuration Change Detection Guide