Web server log analysis is a critical skill in cybersecurity that involves examining HTTP access logs to:

• Detect Security Incidents: Identify attack patterns and suspicious activity
• Investigate Breaches: Understand what attackers accessed and when
• Monitor Traffic: Analyze user behavior and system performance
• Compliance: Meet regulatory requirements for logging and monitoring

Start by examining the access.log file structure and identifying different types of requests:

# Count total log entries
wc -l access.log

# View first few entries
head -10 access.log

# Look for unique HTTP status codes
awk '{print $9}' access.log | sort | uniq -c

# Find unique user agents
awk -F'"' '{print $6}' access.log | sort | uniq

Look for common indicators of malicious activity:

1. Attack Attempts: SQL injection, XSS, and path traversal attempts
2. Scanner Traffic: Requests for common vulnerable files (.env, wp-admin, etc.)
3. Successful Access: 200 status codes from suspicious sources
4. Suspicious User Agents: Automated tools and scanners

# Find potential SQL injection attempts
grep -i "union\|select\|drop\|insert" access.log

# Look for XSS attempts
grep -i "script\|alert\|javascript" access.log

# Find scanner/tool requests
grep -E "(wp-admin|phpmyadmin|\.env|backup)" access.log

# Look for successful requests (200 status) from suspicious sources
grep " 200 " access.log | grep -i "scanner\|tool\|bot"

The key is to find files that attackers successfully accessed (200 status code). Let's examine suspicious entries more closely:

# Look for successful requests from suspicious user agents
grep " 200 " access.log | grep -E "(Scanner|Tool|Bot)"

# Find requests with suspicious referers
grep "attacker" access.log

# Look for successful access to sensitive files
grep " 200 " access.log | grep -E "(backup|config|admin|debug)"

After extensive analysis, you'll find that out of 129 total requests from the attacker (172.16.0.88), only ONE was successful. The key entry revealing successful attacker access:

172.16.0.88 - - [22/Jul/2025:08:32:44 +0000] "GET /backup.txt HTTP/1.1" 200 42 "https://attacker.com/tools" "SecScanner/1.0"

This single successful request is hidden among 128 failed attempts (404/403 status codes), making this a realistic example of how attackers conduct reconnaissance scans.

From the log analysis, we discover that the attacker successfully accessed /backup.txt. The request shows:

• Status Code: 200 (successful access)
• File Size: 42 bytes
• User Agent: SecScanner/1.0 (security scanner)
• Referer: https://attacker.com/tools (suspicious source)

Since the attacker was able to access this file, we should investigate what it contains:

# Access the file that the attacker found
curl https://target-site.com/backup.txt
# OR download it from the challenge page
wget backup.txt

When examining the contents of backup.txt, we find:

FLAG: 1e3e1e7c-6b64-4727-b4bb-6e9945edd9b7

The flag is: 1e3e1e7c-6b64-4727-b4bb-6e9945edd9b7

The security incident reveals several critical findings:

• Attacker IP: 172.16.0.88 (internal network - possible insider threat or compromised host)
• Attack Vector: Automated scanning using SecScanner/1.0
• Discovery Method: Systematic enumeration of common backup file locations
• Exposed File: backup.txt containing sensitive flag information
• Impact: Successful data exfiltration (42 bytes downloaded)
• Attribution: Referer header points to attacker infrastructure

By analyzing the complete log timeline, we can see the attacker's reconnaissance pattern:

1. 08:21:05 - Attempted /admin/login.php (404)
2. 08:30:51 - Attempted /.env file (404)
3. 08:32:44 - Successfully accessed /backup.txt (200) ← FLAG OBTAINED
4. 08:35:39 - Attempted /phpmyadmin/ (404)
5. 08:37:23 - Attempted /config.php.bak (404)
6. 08:39:45 - Attempted /backup/ directory (403)
7. 09:00:44 - Attempted /backup.sql (404)

This shows a systematic approach where the attacker found success with a simple backup.txt file.

This incident demonstrates several security issues:

• Exposed Backup Files: Sensitive backup files left in web-accessible directories
• Insufficient Access Controls: No authentication required for backup.txt
• Poor Security Hygiene: Backup files not properly secured or removed
• Internal Threat: Attack originated from internal network
• Inadequate Monitoring: Successful data exfiltration occurred undetected

Based on this analysis, recommended actions include:

1. Immediate: Remove or secure all backup files from web directories
2. Access Control: Implement proper authentication for sensitive files
3. Network Security: Investigate the compromised internal host (172.16.0.88)
4. Monitoring: Enhance alerting for sensitive file access
5. Policy: Establish secure backup procedures and file retention policies
6. Training: Educate staff on secure file handling practices