Listen to this Post
Introduction:
In modern security operations, the absence of alarms does not equate to the absence of threats. Sophisticated attackers often operate below the alerting threshold, relying on techniques like web shells for persistent, low-and-slow access. This article delves into a realistic Tier 1 Security Operations Center (SOC) threat hunt, demonstrating how correlating disparate log sources—firewall and web server logs—can uncover hidden compromises that evade automated detection systems.
Learning Objectives:
- Master the fundamental techniques for collecting and analyzing firewall and web server logs in a threat-hunting context.
- Develop the analytical skill to correlate events across different log sources to identify suspicious patterns indicative of a web shell deployment.
- Learn practical, immediate containment and eradication steps for a discovered web shell, including system hardening to prevent re-infection.
You Should Know:
1. The Foundation: Gathering and Parsing Critical Logs
Before the hunt begins, you need access to the right data. Firewall logs provide a network-centric view of connections, while web server logs (like those from Apache or Nginx) reveal the application-layer requests. The power lies in correlating an IP address’s behavior across both.
Step‑by‑step guide explaining what this does and how to use it.
On a Linux Server (using command-line tools):
- Firewall Logs (iptables/ufw): Typically located at
/var/log/kern.log,/var/log/syslog, or/var/log/ufw.log. Use `grep` and `awk` to filter for accepted connections.sudo grep "ACCEPT" /var/log/ufw.log | tail -50
- Web Server Logs (Apache): Usually at `/var/log/apache2/access.log` and
error.log. Filter for POST requests to potentially sensitive directories.sudo tail -100 /var/log/apache2/access.log | grep "POST..php"
On a Windows Server (using PowerShell):
- Firewall Logs: Enable logging for dropped/accepted connections via Windows Defender Firewall with Advanced Security. Parsing can be done via PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID='5156'} -MaxEvents 50 | Format-List - IIS Logs: Located by default in
%SystemDrive%\inetpub\logs\LogFiles. Use `Select-String` in PowerShell:Get-Content C:\inetpub\logs\LogFiles\W3SVC1\u_ex240101.log | Select-String "POST" | Select-Object -Last 20
2. Identifying Suspicious IP Activity: The Network Footprint
A single connection is not an incident. Patterns are. Look for an IP that scans multiple ports (e.g., 80, 443, 8080) in firewall logs and then shows successful connections to the web server on port 80/443. The key is high frequency, access to non-standard ports, or sequences of failed then successful access.
Step‑by‑step guide explaining what this does and how to use it.
1. Extract all unique source IPs from your firewall “ACCEPT” logs for the past 24 hours.
sudo awk '/ACCEPT/ {print $12}' /var/log/ufw.log | sort | uniq -c | sort -nr | head -20
(This shows a count of connections per IP; a high count from an unfamiliar external IP is suspicious).
2. Take a candidate IP (e.g., 185.142.236.34) and search for it in your web server access log.
sudo grep "185.142.236.34" /var/log/apache2/access.log
3. Analyze the request URLs. Are they accessing commonly exploited paths like /wp-admin, /uploads/, or /includes/? Are the requests using POST method to `.php` files with unusual query parameters?
- Web Server Log Analysis: The Application Layer Evidence
Web shells are often uploaded via vulnerable forms (e.g., in content management systems) or straight POST requests to a specific file. The access log will show the initial upload request and subsequent command-and-control (C2) requests.
Step‑by‑step guide explaining what this does and how to use it.
1. Search for POST requests to files that shouldn’t normally receive them, like images or new PHP files.
sudo awk '($6 ~ /POST/ && $7 ~ /.(php|jsp|asp)$/) {print $1, $6, $7}' /var/log/apache2/access.log
2. Look for abnormal status codes. A `200 OK` on a POST to `/uploads/tempimage.php` is far more suspicious than a 404.
3. Correlate timestamps. Did the suspicious IP from the firewall logs make a POST request to a new, oddly named file at the exact time the website began experiencing performance issues (the “slow website” symptom)?
4. Detecting and Analyzing the Web Shell Artifact
Once you’ve pinpointed the likely malicious file (e.g., /var/www/html/vendor/update.php), you must analyze it safely. Never execute it.
Step‑by‑step guide explaining what this does and how to use it.
1. Isolate: Move the file to a quarantined, offline analysis environment.
2. Examine: View the code. A classic PHP web shell will contain functions like system(), exec(), shell_exec(), or `eval()` taking input from HTTP parameters (e.g., ?cmd=whoami).
cat /var/www/html/vendor/update.php
Example malicious snippet:
<?php
if(isset($_GET['cmd'])) {
system($_GET['cmd']);
}
?>
3. Hunt for Others: Use command-line tools to search for similar files.
sudo find /var/www/html -name ".php" -type f -exec grep -l "system|exec|shell_exec|eval" {} \;
5. Containment and Eradication: Immediate Response Actions
The goal is to remove the attacker’s access, preserve evidence, and close the initial vector.
Step‑by‑step guide explaining what this does and how to use it.
1. Network Containment: Immediately block the attacker’s IP at the firewall.
– Linux (iptables): `sudo iptables -A INPUT -s 185.142.236.34 -j DROP`
– Windows (PowerShell): `New-NetFirewallRule -DisplayName “Block Threat IP” -Direction Inbound -RemoteAddress 185.142.236.34 -Action Block`
2. Host Containment: Remove the web shell file and any other identified backdoors.
sudo rm -f /var/www/html/vendor/update.php
3. Forensic Snapshot: Take a memory image and a disk snapshot of the affected server if possible, or at least preserve the original logs and malicious files for later analysis.
6. Hardening and Prevention: Closing the Door
Removing the shell is not enough. You must identify and remediate the vulnerability that allowed its upload.
Step‑by‑step guide explaining what this does and how to use it.
1. Patch & Update: Ensure the web application (e.g., WordPress plugin, custom CMS) and server OS are fully patched.
2. File Upload Restrictions: Configure the web server to disallow execution in upload directories.
– Apache (in .htaccess): `php_flag engine off`
– Nginx (in location block): `location ~ /uploads/.\.php$ { return 403; }`
3. Implement Web Application Firewall (WAF): Deploy a WAF like ModSecurity to block common exploit patterns and shell upload attempts.
4. Harden File Permissions: Ensure web directories are not writable by the web server user.
sudo chown -R root:www-data /var/www/html
sudo chmod -R 750 /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
What Undercode Say:
- Correlation is King: The most critical SOC skill isn’t just reading logs, but connecting events across different silos. A firewall log entry is a network fact; a web server log entry is an application fact. Together, they tell the story of an intrusion.
- Assume Breach, Hunt Proactively: The scenario where a “slow website” triggers no alerts is classic. Effective security posturing requires assuming adversaries are already inside and conducting regular, hypothesis-driven hunts on key data sources like logs.
Analysis: This exercise underscores the evolving role of the Tier 1 SOC analyst from alert triager to proactive hunter. The technical steps—log parsing, correlation, and basic digital forensics—are foundational, but the mindset shift is paramount. The attacker’s advantage lies in “slow and low” persistence. The defender’s counter is sustained curiosity and the ability to ask, “What does normal look like, and what deviates from it?” This hands-on practice bridges the gap between theoretical security knowledge and the messy, log-heavy reality of defending live systems. Building these analytical muscles is what transforms a certificate holder into a competent analyst.
Prediction:
The future of such low-and-slow attacks will increasingly leverage AI to generate polymorphic web shell code that further evades signature-based detection and blends in with legitimate traffic. SOC threat hunting will, in turn, become more dependent on AI-driven User and Entity Behavior Analytics (UEBA) to establish sophisticated baselines and flag subtle anomalies. However, the core investigative workflow demonstrated here—hypothesis, log correlation, artifact analysis, and containment—will remain the immutable foundation upon which these advanced tools are built. The human analyst’s critical thinking will remain the decisive factor in uncovering the stealthiest intrusions.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Oluwanifemi Oyeniyi – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
