Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1546.013: PowerShell Profile

Adversaries may gain persistence and elevate privileges by executing malicious content triggered by PowerShell profiles. A PowerShell profile (profile.ps1) is a script that runs when PowerShell starts and can be used as a logon script to customize user environments.

PowerShell supports several profiles depending on the user or host program. For example, there can be different profiles for PowerShell host programs such as the PowerShell console, PowerShell ISE or Visual Studio Code. An administrator can also configure a profile that applies to all users and host programs on the local computer. [1]

Adversaries may modify these profiles to include arbitrary commands, functions, modules, and/or PowerShell drives to gain persistence. Every time a user opens a PowerShell session the modified script will be executed unless the -NoProfile flag is used when it is launched. [2]

An adversary may also be able to escalate privileges if a script in a PowerShell profile is loaded and executed by an account with higher privileges, such as a domain administrator. [3]

EnterpriseT1546.013Sub-techniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

PowerShell profiles matter because they turn a normal administrative convenience into a persistence and privilege-escalation opportunity on Windows. If a profile.ps1 file is modified, malicious PowerShell content can run whenever a user or host program starts PowerShell, and the risk is higher when privileged users open sessions that load the altered profile.

Executive priority

Treat this as a control-validation issue for Windows administrative workstations, servers, and privileged accounts. Leaders should ask whether profile locations are permission-controlled, whether script execution and signing expectations are enforced, and whether SOC/IR teams can prove when PowerShell profile files changed. This technique is especially relevant to audit evidence around least privilege, administrative hardening, and incident scoping for persistence.

Technical view

ATT&CK maps this Windows sub-technique to persistence and privilege escalation under Event Triggered Execution. Because official detection text is not provided, defenders should validate coverage against the related detection strategy, DET0451: Detection Strategy for PowerShell Profile Persistence via profile.ps1 Modification. SOC teams should focus on unauthorized changes to PowerShell profile scripts across user-specific and all-users/all-hosts profile locations, followed by PowerShell launches that would load profiles unless started with -NoProfile. IR teams should review whether modified profile content contains arbitrary commands, functions, modules, or drives and whether the profile was executed by a higher-privileged account.

Likely telemetry

  • File creation, modification, and permission-change events for PowerShell profile scripts such as profile.ps1
  • PowerShell execution telemetry, including session startup context and whether -NoProfile was used
  • PowerShell logging evidence where enabled, such as script execution or module-related records
  • Process creation telemetry for powershell/pwsh host programs and parent-child process context
  • File ownership and access control information for profile directories and scripts

Detection direction

  • Baseline legitimate PowerShell profile use for administrators, developers, automation accounts, PowerShell ISE, Visual Studio Code, and console hosts to reduce false positives.
  • Alert on unexpected creation or modification of profile.ps1 files, especially in all-users/all-hosts locations or by non-administrative accounts.
  • Correlate profile modification events with later PowerShell session starts by privileged users to assess privilege-escalation risk.
  • Tune detections for common blind spots: endpoints without file auditing, PowerShell logging gaps, unmanaged developer workstations, and profile paths outside the SOC’s current file-integrity scope.
  • Use the DET0451 relationship as the primary ATT&CK-supported detection reference, while recognizing the base ATT&CK object does not provide detailed detection logic.

Mitigation priorities

  • Apply M1022 Restrict File and Directory Permissions: remove unnecessary write access to PowerShell profile files and directories, especially profiles that apply to all users or all host programs.
  • Apply M1045 Code Signing where practical so trusted scripts can be distinguished from unauthorized or tampered content.
  • Apply M1054 Software Configuration by reviewing PowerShell and host application settings, including whether routine administrative workflows should launch PowerShell with profile loading disabled where appropriate.
  • Prioritize privileged accounts and administrative systems first, then expand to broader Windows endpoint coverage.
  • Include PowerShell profile locations in configuration baselines, change monitoring, and incident response persistence checks.
Analyst notes and limits

This object replaces revoked technique T1504 and is now represented as sub-technique T1546.013 under Event Triggered Execution. The supplied relationship context includes Turla use, but that should be treated as historical ATT&CK procedure context, not evidence of current activity in any environment.

Official ATT&CK detection guidance is not provided for this object, so local detection design must be based on the related DET0451 strategy, PowerShell profile documentation, available Windows telemetry, and environment-specific baselines. The supplied data supports Windows only and does not justify claims about active exploitation or guaranteed detection.

Official MITRE ATT&CK definition

PowerShell Profile

Adversaries may gain persistence and elevate privileges by executing malicious content triggered by PowerShell profiles. A PowerShell profile (profile.ps1) is a script that runs when PowerShell starts and can be used as a logon script to customize user environments.

PowerShell supports several profiles depending on the user or host program. For example, there can be different profiles for PowerShell host programs such as the PowerShell console, PowerShell ISE or Visual Studio Code. An administrator can also configure a profile that applies to all users and host programs on the local computer. [1]

Adversaries may modify these profiles to include arbitrary commands, functions, modules, and/or PowerShell drives to gain persistence. Every time a user opens a PowerShell session the modified script will be executed unless the -NoProfile flag is used when it is launched. [2]

An adversary may also be able to escalate privileges if a script in a PowerShell profile is loaded and executed by an account with higher privileges, such as a domain administrator. [3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1546 Event Triggered Execution This object subtechnique of Event Triggered Execution.
Enterprise T1504 PowerShell Profile PowerShell Profile revoked by this object.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0010: Turla

Turla is a cyber espionage threat group that has been attributed to Russia's Federal Security Service (FSB). They have compromised victims in over 50 countries since at least 2004, spanning a range of industries including government, embassies, military, education, research and pharmaceutical companies. Turla is known for conducting watering hole and spearphishing campaigns, and leveraging in-house tools and malware, such as Uroburos.[1][2][3][4][5]

Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1546: Event Triggered Execution Enterprise uses · Group G0010: Turla Enterprise mitigates · Mitigation M1045: Code Signing Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise mitigates · Mitigation M1054: Software Configuration Enterprise detects · Detection Strategy DET0451: Detection Strategy for PowerShell Profile Persistence via profile.ps1 Modification Enterprise revoked by · Technique T1504: PowerShell Profile Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

Mitigation Enterprise

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Change history

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 .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
756794784e329926...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle 756794784e32…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Microsoft About Profiles

    Microsoft. (2017, November 29). About Profiles. Retrieved June 14, 2019.

    Open source URL
  2. [2]
    ESET Turla PowerShell May 2019

    Faou, M. and Dumont R.. (2019, May 29). A dive into Turla PowerShell usage. Retrieved June 14, 2019.

    Open source URL
  3. [3]
    Wits End and Shady PowerShell Profiles

    DeRyke, A.. (2019, June 7). Lab Notes: Persistence and Privilege Elevation using the Powershell Profile. Retrieved July 8, 2019.

    Open source URL
  4. [4]
    Malware Archaeology PowerShell Cheat Sheet

    Malware Archaeology. (2016, June). WINDOWS POWERSHELL LOGGING CHEAT SHEET - Win 7/Win 2008 or later. Retrieved June 24, 2016.

    Open source URL
  5. [5]
    Microsoft Profiles

    Microsoft. (2021, September 27). about_Profiles. Retrieved February 4, 2022.

    Open source URL
  6. [6]
    mitre-attack T1546.013
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use