PowerShell Profile Modification

Hunt Hypothesis

The PowerShell Profile Modification rule detects potential adversary behavior where an attacker alters or creates a PowerShell profile to establish persistence. SOC teams should proactively hunt for this activity in Azure Sentinel as modified profiles can be used to execute malicious code persistently across system reboots.

Detection Rule

Sigma (Original)

title: PowerShell Profile Modification
id: b5b78988-486d-4a80-b991-930eff3ff8bf
status: test
description: Detects the creation or modification of a powershell profile which could indicate suspicious activity as the profile can be used as a mean of persistence
references:
    - https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/
    - https://persistence-info.github.io/Data/powershellprofile.html
author: HieuTT35, Nasreddine Bencherchali (Nextron Systems)
date: 2019-10-24
modified: 2023-10-23
tags:
    - attack.persistence
    - attack.privilege-escalation
    - attack.t1546.013
logsource:
    product: windows
    category: file_event
detection:
    selection:
        TargetFilename|endswith:
            - '\Microsoft.PowerShell_profile.ps1'
            - '\PowerShell\profile.ps1'
            - '\Program Files\PowerShell\7-preview\profile.ps1'
            - '\Program Files\PowerShell\7\profile.ps1'
            - '\Windows\System32\WindowsPowerShell\v1.0\profile.ps1'
            - '\WindowsPowerShell\profile.ps1'
    condition: selection
falsepositives:
    - System administrator creating Powershell profile manually
level: medium

KQL (Azure Sentinel)

imFileEvent
| where TargetFileName endswith "\\Microsoft.PowerShell_profile.ps1" or TargetFileName endswith "\\PowerShell\\profile.ps1" or TargetFileName endswith "\\Program Files\\PowerShell\\7-preview\\profile.ps1" or TargetFileName endswith "\\Program Files\\PowerShell\\7\\profile.ps1" or TargetFileName endswith "\\Windows\\System32\\WindowsPowerShell\\v1.0\\profile.ps1" or TargetFileName endswith "\\WindowsPowerShell\\profile.ps1"

False Positive Guidance

• Scenario: System Administrator Updates PowerShell Profile for Custom Aliases
  Description: A sysadmin modifies their PowerShell profile to define custom aliases for easier command execution.
  Filter/Exclusion: Check for the presence of known admin tools or scripts (e.g., Set-Alias, Import-Module) in the profile file. Exclude profiles located in the user’s personal directory ($PROFILE).

• Scenario: Scheduled Job Uses PowerShell Profile for Initialization
  Description: A legitimate scheduled job uses a PowerShell profile to load common functions or modules during execution.
  Filter/Exclusion: Filter by the job name or script path. Exclude modifications to profiles used by scheduled tasks (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1).

• Scenario: Security Tool Installs a PowerShell Profile for Monitoring
  Description: A security tool like Microsoft Defender ATP or CrowdStrike installs a PowerShell profile to monitor script activity.
  Filter/Exclusion: Exclude profiles created by known security tools. Check the file’s content for security tool-specific functions or modules.

• Scenario: User Installs a Third-Party Module via Profile
  Description: A user adds a third-party module (e.g., Pester, PSReadLine) to their profile for convenience.
  Filter/Exclusion: Exclude profiles that include module import statements for commonly used, legitimate modules. Check for module names in the profile content.

• Scenario: PowerShell Profile Used for Environment Setup
  Description: A developer’s profile is modified to set environment variables or paths for their development tools (e.g., Docker, Visual Studio Code).
  Filter/Exclusion: Exclude profiles that contain environment variable assignments or path modifications for known development tools. Check for tool-specific variables like PSModulePath or

MITRE ATT&CK Context

• Tactic: Persistence
• Tactic: Privilege Escalation
• Technique: T1546.013