Adversaries may be creating a PowerShell module to execute malicious code or establish persistence. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential initial compromise vectors and mitigate advanced threats.
Detection Rule
title: Potential Suspicious PowerShell Module File Created
id: e8a52bbd-bced-459f-bd93-64db45ce7657
status: test
description: Detects the creation of a new PowerShell module in the first folder of the module directory structure "\WindowsPowerShell\Modules\malware\malware.psm1". This is somewhat an uncommon practice as legitimate modules often includes a version folder.
references:
- Internal Research
- https://learn.microsoft.com/en-us/powershell/scripting/developer/module/understanding-a-windows-powershell-module?view=powershell-7.3
author: Nasreddine Bencherchali (Nextron Systems)
date: 2023-05-09
tags:
- attack.persistence
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|endswith:
# Note: Don't include PowerShell 7 as it has default modules that don't follow this logic
- '\\WindowsPowerShell\\Modules\\*\.ps'
- '\\WindowsPowerShell\\Modules\\*\.dll'
condition: selection
falsepositives:
- False positive rate will vary depending on the environments. Additional filters might be required to make this logic usable in production.
level: medium
imFileEvent
| where (TargetFileName contains "\\WindowsPowerShell\\Modules\\" and TargetFileName contains "\\.ps") or (TargetFileName contains "\\WindowsPowerShell\\Modules\\" and TargetFileName contains "\\.dll")Scenario: A system administrator is deploying a legitimate PowerShell module using Publish-Module from the PowerShell Gallery.
Filter/Exclusion: Check the ModuleName field against known trusted repositories (e.g., PSGallery) and verify the source is a trusted URL.
Scenario: A scheduled job is configured to run a PowerShell script that creates a temporary module file in the module directory for runtime use (e.g., Import-Module with a local .psm1 file).
Filter/Exclusion: Filter based on the FilePath containing known temporary directories or paths used by scheduled jobs (e.g., C:\Windows\Temp).
Scenario: An IT admin is using Import-Module to load a custom module for internal tooling, such as a script that automates user provisioning.
Filter/Exclusion: Exclude files that match known internal module names or paths (e.g., C:\ITTools\Modules\InternalModule.psm1).
Scenario: A user is running a legitimate PowerShell script that dynamically creates a module file as part of a configuration setup (e.g., a setup script for a third-party application).
Filter/Exclusion: Exclude files created in specific directories used by setup scripts (e.g., C:\ProgramData\SetupScript\Modules) or based on the script’s hash.
Scenario: A system update or patching tool creates a temporary PowerShell module file in the module directory to apply configuration changes.
Filter/Exclusion: Exclude files created in directories associated with patching tools (e.g., C:\Windows\Temp\patching) or based on the process name (e.g., WindowsUpdate.exe).