Listen to this Post
Introduction
Webshells remain a persistent threat to Internet Information Services (IIS) servers, often slipping past basic logging configurations. Attackers exploit weak logging practices to maintain stealthy access, making detection difficult. This guide covers essential logging enhancements, attack simulations, and hunting techniques to secure your IIS infrastructure.
Learning Objectives
- Enable advanced IIS logging for better threat detection.
- Understand how attackers abuse IIS modules.
- Simulate and hunt webshell attacks using SequelEyes and Splunk.
You Should Know
1. Enable IIS Operational Logging and Custom Fields
Why it matters: Default IIS logs lack critical forensic data. Operational logging captures module-level activity, exposing malicious behavior.
Steps to Enable:
1. Open IIS Manager → Select your server.
- Navigate to Logging → Click View Log Files.
3. Enable W3C logging and add custom fields:
PowerShell: Add custom logging fields
Set-WebConfigurationProperty -Filter "system.applicationHost/sites/siteDefaults/logFile/customFields" -Name "." -Value @{
logFieldName="Client-IP"; sourceName="REMOTE_ADDR"
}
4. Restart IIS:
iisreset /restart
2. Monitor Suspicious IIS Module Activity
Why it matters: Attackers load malicious modules to execute code silently.
Detection Command (PowerShell):
Get-WebGlobalModule | Where-Object { $_.Name -notin @("UriCacheModule", "StaticCompressionModule") } | Format-Table Name, Image
Action: Investigate unknown modules and remove unauthorized ones.
3. Simulate Webshell Attacks with SequelEyes
Why it matters: Testing defenses helps identify logging gaps.
Steps:
1. Clone SequelEyes (a webshell simulator):
git clone https://github.com/example/SequelEyes
2. Execute a simulated attack:
python sequelEyes.py --target http://your-iis-server --payload "cmd /c whoami"
3. Verify logs for anomalies.
4. Hunt Webshells in Splunk
Why it matters: Splunk queries can detect webshell activity.
Sample Query:
index=iis_logs status=200 uri_path=.asp | stats count by client_ip, uri_path | where count > 50
Key Indicators:
- Unusual
.asp/.aspxrequests. - High-frequency POSTs to obscure paths.
5. Block Malicious Requests via URL Rewrite
Why it matters: Prevents webshell uploads via crafted requests.
Rule (web.config):
<rule name="Block Webshell Uploads" stopProcessing="true">
<match url=".\.(ashx|aspx|php)" />
<conditions>
<add input="{REQUEST_METHOD}" pattern="POST" />
</conditions>
<action type="AbortRequest" />
</rule>
6. Enable Audit Logging for File Changes
Why it matters: Webshells often modify web directories.
PowerShell Command:
auditpol /set /subcategory:"File System" /success:enable /failure:enable
7. Deploy File Integrity Monitoring (FIM)
Why it matters: Alerts on unauthorized file changes.
Using Sysinternals (Command Line):
sigcheck -t -h C:\inetpub\wwwroot
What Undercode Say
- Key Takeaway 1: Basic IIS logging is insufficient—operational logs and custom fields are critical.
- Key Takeaway 2: Attackers abuse trusted modules; continuous monitoring is essential.
Analysis: Organizations often focus on perimeter defenses but neglect logging depth. Attackers exploit these blind spots, making post-breach detection difficult. Proactive simulation (e.g., SequelEyes) and Splunk-based hunting bridge this gap.
Prediction
As attackers refine evasion techniques, IIS servers with weak logging will face increased compromise rates. Future threats may leverage AI-driven obfuscation, making real-time log analysis and automation indispensable.
Final Thought: Strengthen logging now—or risk invisible breaches. 🚨
IT/Security Reporter URL:
Reported By: Michaelahaag Webshells – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
