On June 3, 2026, Huntress analysts uncovered a concerning evolution in attacker tooling: a custom PowerShell script designed for Active Directory reconnaissance, generated by Artificial Intelligence. This incident, investigated by analyst Jevon Ang, confirms a long-feared hypothesis—adversaries are leveraging Large Language Models (LLMs) to rapidly build malware that bypasses traditional static signatures.
Unlike standard off-the-shelf tools like PowerView or ADMiner, this AI-generated script presents unique code structures and variable naming conventions, rendering signature-based detection ineffective for many endpoint protection platforms (EPP). This is no longer a theoretical risk; it is active exploitation targeting Windows Servers to map domain structures, identify high-privilege accounts, and prepare for lateral movement or ransomware deployment. Defenders must shift focus from known-bad signatures to behavioral analysis and robust logging.
Technical Analysis
- Affected Products: Windows Server (Active Directory environments), PowerShell 5.1/7.x.
- Threat Type: Custom Reconnaissance / Living-off-the-Land (LOLBins) enhancement.
- Mechanism: The attacker utilized an AI model to generate PowerShell code capable of querying Active Directory. While the core functionality likely utilizes native .NET classes or standard cmdlets (e.g.,
System.DirectoryServices.DirectorySearcherorGet-ADUser), the implementation is unique. - Exploitation Status: Confirmed active exploitation (In-the-wild).
- Risk: Traditional hash-based defenses fail. The script likely performs discovery of users, groups, and trust relationships to facilitate credential theft or privilege escalation.
Detection & Response
Detecting AI-generated code requires identifying the intent rather than the hash. We must monitor for suspicious combinations of PowerShell execution and Active Directory interaction, particularly when executed from non-standard contexts or with encoding.
SIGMA Rules
---
title: Suspicious PowerShell Active Directory Discovery
id: 8a5f2c13-1d4b-4e8f-9a0b-2c3d4e5f6a7b
status: experimental
description: Detects PowerShell scripts performing AD discovery via System.DirectoryServices or Get-AD cmdlets, often seen in custom recon tools.
references:
- https://attack.mitre.org/techniques/T1087/
- https://attack.mitre.org/techniques/T1069/
author: Security Arsenal
date: 2026/06/04
tags:
- attack.discovery
- attack.t1087
- attack.t1069
logsource:
category: process_creation
product: windows
detection:
selection_cmdlets:
CommandLine|contains:
- 'Get-ADUser'
- 'Get-ADComputer'
- 'Get-ADGroup'
- 'Get-ADGroupMember'
- 'Get-ADDomain'
selection_dotnet:
CommandLine|contains:
- 'System.DirectoryServices.DirectorySearcher'
- 'System.DirectoryServices.ActiveDirectory'
condition: 1 of selection_*
falsepositives:
- Administration scripts
- Inventory tools
level: medium
---
title: PowerShell Script Block Logging for Encoded AD Recon
id: 9b6e3d24-2e5c-5f9g-0b1c-3d4e5f6a7b8c
status: experimental
description: Detects encoded or obfuscated PowerShell command lines attempting to access Active Directory data.
references:
- https://attack.mitre.org/techniques/T1027/
author: Security Arsenal
date: 2026/06/04
tags:
- attack.defense_evasion
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection_encoded:
CommandLine|contains:
- 'FromBase64String'
- 'ToBase64String'
- '-EncodedCommand'
selection_ad_keywords:
CommandLine|contains:
- 'DirectorySearcher'
- 'GetObject'
- 'LDAP:'
condition: selection_encoded and selection_ad_keywords
falsepositives:
- Legitimate encoded deployment scripts
level: high
KQL (Microsoft Sentinel / Defender)
// Hunt for PowerShell processes utilizing AD cmdlets or .NET classes for discovery
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FolderPath endswith @"\powershell.exe" or FolderPath endswith @"\pwsh.exe"
| where ProcessCommandLine has "Get-ADUser" or
ProcessCommandLine has "Get-ADComputer" or
ProcessCommandLine has "DirectorySearcher" or
ProcessCommandLine has "System.DirectoryServices"
// Filter out common legitimate management locations
| where not (InitiatingProcessFolderPath contains @"\System32\" or InitiatingProcessFolderPath contains @"\Program Files\")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, SHA256
| extend Tactic = "Discovery", Technique = "Active Directory Enumeration"
Velociraptor VQL
-- Hunt for PowerShell processes with AD discovery indicators
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'powershell.exe' OR Name =~ 'pwsh.exe'
AND (
CommandLine =~ 'Get-AD' OR
CommandLine =~ 'DirectorySearcher' OR
CommandLine =~ 'System.DirectoryServices'
)
-- Context: Look for processes spawned from temp folders or suspicious parents
Remediation Script (PowerShell)
# Script to Harden PowerShell Logging for AD Recon Detection
# Must be run as Administrator
Write-Host "Enabling PowerShell Script Block Logging..." -ForegroundColor Cyan
$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
if (-not (Test-Path $registryPath)) {
New-Item -Path $registryPath -Force | Out-Null
}
Set-ItemProperty -Path $registryPath -Name "EnableScriptBlockLogging" -Value 1 -Force
Set-ItemProperty -Path $registryPath -Name "EnableScriptBlockInvocationLogging" -Value 1 -Force
Write-Host "Enabling Module Logging for Active Directory..." -ForegroundColor Cyan
$modulePath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging"
if (-not (Test-Path $modulePath)) {
New-Item -Path $modulePath -Force | Out-Null
}
Set-ItemProperty -Path $modulePath -Name "EnableModuleLogging" -Value 1 -Force
$modulesPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames"
if (-not (Test-Path $modulesPath)) {
New-Item -Path $modulesPath -Force | Out-Null
}
# Log specific AD modules or all
Set-ItemProperty -Path $modulesPath -Name "*" -Value "*" -Force
Write-Host "Hardening applied. Review Event ID 4103/4104 for script activity." -ForegroundColor Green
Remediation
Since this attack relies on PowerShell to perform queries, "patching" isn't about a specific CVE, but about configuration hygiene:
- Enable PowerShell Logging: Ensure Script Block Logging (Event ID 4104) and Module Logging are enabled via Group Policy. This is the only reliable way to see what custom scripts are actually doing, even if they are AI-generated and obfuscated.
- Just-In-Time (JIT) Access: Restrict the use of administrative accounts and PowerShell remoting. Revoke standing privileges for domain admins.
- Application Control: Implement AppLocker or Windows Defender Application Control (WDAC) to restrict PowerShell execution to specific signed scripts or directories.
- Network Segmentation: Limit access to Domain Controllers. Only necessary management servers should be able to initiate LDAP/RPC connections to DCs.
- User Training: Ensure staff are aware that social engineering prompts are often used to get them to run AI-generated code, effectively bypassing security controls.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.