M1039: Environment Variable Permissions
Restrict the modification of environment variables to authorized users and processes by enforcing strict permissions and policies. This ensures the integrity of environment variables, preventing adversaries from abusing or altering them for malicious purposes. This mitigation can be implemented through the following measures:
Restrict Write Access:
- Use Case: Set file system-level permissions to restrict access to environment variable configuration files (e.g., `.bashrc`, `.bash_profile`, `.zshrc`, `systemd` service files). - Implementation: Configure `/etc/environment` or `/etc/profile` on Linux systems to only allow root or administrators to modify the file.
Secure Access Controls:
- Use Case: Limit access to environment variable settings in application deployment tools or CI/CD pipelines to authorized personnel. - Implementation: Use role-based access control (RBAC) in tools like Jenkins or GitLab to ensure only specific users can modify environment variables.
Restrict Process Scope:
- Use Case: Configure policies to ensure environment variables are only accessible to the processes they are explicitly intended for. - Implementation: Use containerized environments like Docker to isolate environment variables to specific containers and ensure they are not inherited by other processes.
Audit Environment Variable Changes:
- Use Case: Enable logging for changes to critical environment variables. - Implementation: Use `auditd` on Linux to monitor changes to files like `/etc/environment` or application-specific environment files.
Analyst context for executives and security teams
Environment variable permissions matter because small configuration changes can weaken auditability. In the supplied ATT&CK context, this mitigation is especially relevant to command history integrity: adversaries may clear or prevent command history logging by influencing variables such as history file settings. For leaders, the practical issue is whether administrators, build systems, deployment tools, and services can change environment settings without appropriate authorization or logging.
Executive priority
Prioritize this as a control validation item for systems where shell history, service configuration, CI/CD variables, or application environment settings support incident reconstruction and accountability. The business value is not only prevention; it is preserving evidence for incident response, compliance review, and operational resilience. Leaders should ask who can modify environment variable configuration, whether those changes are logged, and whether privileged access or deployment tooling can bypass normal change control.
Technical view
Validate permissions and change control around environment variable sources identified by ATT&CK, including Linux shell/profile files such as .bashrc, .bash_profile, .zshrc, /etc/environment, /etc/profile, systemd service files, application-specific environment files, CI/CD or deployment-tool variable stores, and container-scoped variables. Relationship context ties this mitigation to Clear Command History and Prevent Command History Logging, where variables such as HISTFILE and HISTCONTROL can affect command history evidence. SOC and IR teams should confirm whether changes to these files or settings are captured, attributable to a user or process, and correlated with privileged sessions or suspicious history gaps.
Likely telemetry
- File permission and ownership state for environment variable configuration files
- File modification events for shell profile files, /etc/environment, /etc/profile, systemd service files, and application-specific environment files
- Linux auditd records for monitored environment configuration files where enabled
- CI/CD or application deployment tool audit logs for environment variable changes and RBAC activity
- Container or service configuration records showing variable scope and inheritance
Detection direction
- MITRE does not provide an official detection for this mitigation, so coverage should be validated locally through control testing and telemetry review.
- Alert or review unauthorized or unexpected writes to environment variable configuration files, especially by non-administrative users or processes not associated with approved change workflows.
- Tune detections to distinguish expected administrative maintenance, deployments, and service updates from unapproved changes; change tickets and CI/CD audit logs are useful context.
- For the related command-history techniques, look for changes to variables or files that affect history retention alongside missing, truncated, or redirected shell history evidence.
- Assess blind spots in deployment tools, CI/CD variable stores, containers, and service managers, because environment variables may be changed outside traditional endpoint file monitoring.
Mitigation priorities
- Restrict write access to environment variable configuration files so only authorized administrators or root-equivalent roles can modify them.
- Apply RBAC and change control to CI/CD and application deployment tools that manage environment variables.
- Limit environment variable scope so variables are available only to intended processes, services, or containers rather than broadly inherited.
- Enable auditing for changes to critical environment variable files and application-specific environment settings.
- Periodically review permissions, ownership, and access policies for environment variable sources that affect command history, service behavior, or application execution context.
Analyst notes and limits
This mitigation is a governance and hardening control as much as a technical setting. Its value is highest where environment variables influence evidence retention, service execution, or deployment behavior. The supplied relationships connect it specifically to techniques involving command history clearing or prevention, so validation should include both configuration integrity and the ability to reconstruct user activity during IR.
The ATT&CK mitigation object does not specify platforms or provide official detection logic. Platform examples and telemetry direction are limited to the official description and the two supplied relationships. Local operating systems, shells, service managers, CI/CD tools, and container platforms determine the exact files, logs, and control owners to validate.
Environment Variable Permissions
Restrict the modification of environment variables to authorized users and processes by enforcing strict permissions and policies. This ensures the integrity of environment variables, preventing adversaries from abusing or altering them for malicious purposes. This mitigation can be implemented through the following measures:
Restrict Write Access:
- Use Case: Set file system-level permissions to restrict access to environment variable configuration files (e.g., `.bashrc`, `.bash_profile`, `.zshrc`, `systemd` service files). - Implementation: Configure `/etc/environment` or `/etc/profile` on Linux systems to only allow root or administrators to modify the file.
Secure Access Controls:
- Use Case: Limit access to environment variable settings in application deployment tools or CI/CD pipelines to authorized personnel. - Implementation: Use role-based access control (RBAC) in tools like Jenkins or GitLab to ensure only specific users can modify environment variables.
Restrict Process Scope:
- Use Case: Configure policies to ensure environment variables are only accessible to the processes they are explicitly intended for. - Implementation: Use containerized environments like Docker to isolate environment variables to specific containers and ensure they are not inherited by other processes.
Audit Environment Variable Changes:
- Use Case: Enable logging for changes to critical environment variables. - Implementation: Use `auditd` on Linux to monitor changes to files like `/etc/environment` or application-specific environment files.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1690 | Prevent Command History Logging | Prevent users from changing the |
| Enterprise | T1070.003 | Clear Command History Sub-technique | Making the environment variables associated with command history read only may ensure that the history is preserved.CitationSecuring bash history |
All related ATT&CK context
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.1 | Current bundle | 3e31eb8c47eb… |
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 M1039Open 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.