Listen to this Post
Introduction:
Web servers constantly face a deluge of automated scanners probing for known vulnerabilities, particularly WordPress installation scripts. Attackers leverage bots to blindly hit endpoints like /wp-admin/install.php, hoping to find unconfigured CMS instances they can exploit. This reconnaissance technique, mapped to MITRE ATT&CK T1595 (Active Scanning), generates log noise, wastes CPU cycles, and masks real threats. By deploying a smart honeypot that detects requests for non-existent CMS paths and instantly blocks offenders with zero tolerance, security teams can transform passive logging into active defense—sanctioning scanners after a single suspicious hit.
Learning Objectives:
- Understand how Layer 7 honeypots identify and block automated CMS scanners using `maxretry=1` policies
- Implement real-time IP blocking with Linux
iptables,fail2ban, and custom blocklist integration - Analyze attacker behavior through fake WordPress endpoints and User-Agent spoofing detection
You Should Know:
- Deploying a Lightweight CMS Honeypot with Nginx and Lua
Attackers often scan for `/wp-admin/install.php` or `/wp-login.php` regardless of whether WordPress exists. A honeypot can be set up on any server to trap these requests.
Step‑by‑step guide – Linux (Ubuntu/Debian):
Install Nginx with Lua support
sudo apt update && sudo apt install nginx-extras lua5.3
Create a fake WordPress directory structure
sudo mkdir -p /var/www/html/wp-admin
sudo mkdir -p /var/www/html/wp-content
Create a deceptive install.php script
sudo tee /var/www/html/wp-admin/install.php > /dev/null << 'EOF'
<?php
// Fake WordPress installer - logging only
$log_entry = date('Y-m-d H:i:s') . " - " . $_SERVER['REMOTE_ADDR'] .
" - " . $_SERVER['REQUEST_URI'] . " - " . $_SERVER['HTTP_USER_AGENT'] . PHP_EOL;
file_put_contents('/var/log/wp_honeypot.log', $log_entry, FILE_APPEND);
http_response_code(403);
echo "Access denied.";
?>
EOF
Configure Nginx to log and block on first hit
sudo tee /etc/nginx/sites-available/honeypot << 'EOF'
server {
listen 80;
server_name _;
access_log /var/log/nginx/honeypot_access.log;
error_log /var/log/nginx/honeypot_error.log;
location ~ /wp-(admin|login|content) {
Log the attempt
access_log /var/log/nginx/wp_scanner.log combined;
Return 403 and invoke block script
return 403;
Alternative: proxy to a real blocking endpoint
post_action @block_ip;
}
location @block_ip {
internal;
proxy_pass http://127.0.0.1:8080/block?ip=$remote_addr;
}
}
EOF
Automated blocking with a simple Bash script:
!/bin/bash
/usr/local/bin/block_scanner.sh
LOG_FILE="/var/log/nginx/wp_scanner.log"
BLOCKLIST="/etc/nginx/blocked_ips.conf"
DATA_SHIELD_LIST="/etc/data-shield-ipv4.txt"
tail -Fn0 "$LOG_FILE" | while read line; do
IP=$(echo "$line" | grep -oE '([0-9]{1,3}.){3}[0-9]{1,3}' | head -1)
if [[ -1 "$IP" && $(grep -c "$IP" "$BLOCKLIST") -eq 0 ]]; then
echo "deny $IP;" >> "$BLOCKLIST"
Reload Nginx to apply block
sudo nginx -s reload
Additionally add to iptables (immediate kernel-level block)
sudo iptables -A INPUT -s "$IP" -j DROP
echo "$(date): Blocked $IP (first hit on fake CMS)" >> /var/log/block_actions.log
fi
done
How to use it:
Place the script in /usr/local/bin/, make it executable (chmod +x), and run it as a systemd service or within screen. Every time a scanner hits the honeypot path, the script logs the IP and instantly adds it to both Nginx deny list and iptables—achieving the `maxretry=1` zero-tolerance policy described in the original post.
2. Parsing User-Agent Spoofing and Referer Trails
Attackers often disguise bots with legitimate User-Agents like `Discordbot/2.0` to evade simple filters. The original post highlights a scanner using this exact trick. Analyzing logs reveals the deception.
Linux command to extract suspicious patterns:
Monitor real-time requests to fake WordPress paths
sudo tail -f /var/log/nginx/access.log | grep "wp-admin/install.php"
Find all unique User-Agents hitting the honeypot
sudo awk '/wp-admin\/install.php/ {print $12}' /var/log/nginx/access.log | sort -u
Count hits per IP with spoofed Discordbot UA
sudo grep "Discordbot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -1r
Windows PowerShell equivalent (IIS or WSL):
Using Get-Content and Select-String
Get-Content "C:\inetpub\logs\LogFiles\W3SVC1\u_ex.log" | Select-String "wp-admin/install.php" | ForEach-Object {
$_.Line.Split()[bash] Extract IP column (adjust index based on IIS format)
} | Group-Object | Sort-Object Count -Descending
Detect spoofed User-Agents
Get-Content "C:\logs\access.log" | Select-String "Discordbot" | Select-String "wp-admin"
Why this matters:
Legitimate Discordbot accesses `/.well-known/discord` or API endpoints—never a CMS installer. Spotting such mismatches indicates automated scanning. Security teams should feed these IPs into threat intelligence feeds like Data-Shield IPv4 Blocklists for community protection.
- Implementing Zero-Tolerance Blocking with Fail2ban and Custom Actions
Fail2ban is ideal for translating `maxretry=1` into automatic bans. Below is a custom jail for the honeypot.
Step‑by‑step – Linux:
Install fail2ban sudo apt install fail2ban -y Create a filter for WordPress scanner detection sudo tee /etc/fail2ban/filter.d/wp-honeypot.conf << 'EOF' [bash] failregex = ^<HOST> . "GET /wp-(admin|login|content).install.php." 403 ^<HOST> . "GET /wp-config.php." 403 ignoreregex = EOF Create a custom action that also updates Data-Shield format sudo tee /etc/fail2ban/action.d/data-shield-block.conf << 'EOF' [bash] actionstart = actionstop = actioncheck = actionban = iptables -I INPUT -s <ip> -j DROP echo "<ip> banned by fail2ban on $(date)" >> /etc/data-shield-custom.list actionunban = iptables -D INPUT -s <ip> -j DROP EOF Configure the jail with ban time and maxretry=1 sudo tee /etc/fail2ban/jail.local << 'EOF' [wp-honeypot] enabled = true filter = wp-honeypot logpath = /var/log/nginx/access.log maxretry = 1 findtime = 3600 bantime = 86400 action = data-shield-block sendmail-whois[name=WP-Honeypot, [email protected]] EOF sudo systemctl restart fail2ban
Verification commands:
Check fail2ban status sudo fail2ban-client status wp-honeypot View currently banned IPs sudo iptables -L INPUT -1 | grep DROP See fail2ban logs sudo tail -f /var/log/fail2ban.log
With maxretry=1, the very first request to a non-existent WordPress path triggers an immediate 24-hour ban, exactly as SysWarden’s engine operates.
4. Hardening Real CMS Installations Against Scanner Noise
If you run legitimate WordPress, scanners still probe. The honeypot approach can be inverted: redirect scanner traffic to a dead end while preserving real user access.
Nginx rule to distinguish legitimate traffic from bots:
In your real WordPress site config
location /wp-admin/install.php {
If file exists (real WordPress), serve normally
try_files $uri $uri/ =404;
Log all attempts
access_log /var/log/nginx/wp_install_probes.log;
Block known scanner IPs (loaded from data-shield list)
include /etc/nginx/data-shield-blocked.conf;
}
Separate honeypot for non-existent paths (catch-all)
location ~ ^/wp-(?!content|admin|includes)..php$ {
return 403;
access_log /var/log/nginx/honeypot_catch.log;
}
API security parallel:
This same logic applies to API endpoints. Implement a fake `/api/v1/admin/setup` endpoint that logs and blocks any caller. For cloud hardening, use AWS WAF or Cloudflare rules with rate-based blocking set to `1 request per 5 minutes` for suspicious URI patterns.
5. Contributing to Data-Shield IPv4 Blocklists
The original post mentions enriching Data-Shield IPv4 Blocklists. Here’s how to format and submit your honeypot’s findings.
Generate a compatible blocklist from your logs:
Extract unique IPs that hit the honeypot in the last 24 hours
awk '{print $1}' /var/log/nginx/wp_scanner.log | sort -u > /tmp/scanner_ips.txt
Convert to Data-Shield format (CIDR or single IP)
while read ip; do
Validate IP format
if [[ $ip =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then
echo "$ip/32 honeypot detected on $(date +%Y-%m-%d)"
fi
done < /tmp/scanner_ips.txt >> /opt/data-shield-contributions.txt
Submit via API (example)
curl -X POST https://api.data-shield.io/v1/submit \
-H "Authorization: Bearer YOUR_API_KEY" \
-F "list=@/opt/data-shield-contributions.txt"
Windows batch alternative:
@echo off
for /f "tokens=1 delims= " %%i in ('findstr "wp-admin/install.php" C:\logs\access.log') do (
echo %%i/32 >> C:\data-shield\contributions.txt
)
By sharing blocked IPs, you help the community preemptively deny access to known scanners—reducing everyone’s log pollution.
What Undercode Say:
- Zero tolerance transforms defense: Setting `maxretry=1` on non-existent CMS paths flips the asymmetry—attackers expect multiple retries, but instant blocking exhausts their scanning resources.
- Honeypots generate actionable intelligence: Every blocked scanner provides an IP that can be fed into blocklists, turning noise into a community resource. The original post’s mention of “enriching Data-Shield lists” is a force multiplier.
Analysis: The tactic described—using a fake WordPress installer as bait—exploits the most common automated behavior on the web. Attackers rarely customize their scanners per target; they spray generic payloads. By responding with a 403 and immediate kernel-level block after a single probe, the defender not only stops that scanner but also prevents any follow-up attacks from the same IP (e.g., credential stuffing, XML-RPC exploits). The CPU savings are real because the web server never fully processes the request—the block happens before PHP execution. For SOC analysts, logs become cleaner, allowing focus on genuine intrusion attempts rather than background noise.
Prediction:
- +1 Widespread adoption of `maxretry=1` honeypots will force attackers to slow down dramatically, making mass scanning economically unviable and pushing threat actors toward targeted, slower reconnaissance that is easier to detect.
- -1 Adversaries will evolve by rotating IPs more rapidly and using residential proxies, rendering single-IP blocking less effective and requiring behavioral analysis across distributed sources.
- +1 Integration of honeypot data into centralized blocklists (like Data-Shield) will create a real-time reputation network, where a scanner blacklisted by one server is instantly denied by thousands—reducing the attacker’s ROI.
- -1 Attackers may shift to probing via legitimate CDN IPs (Cloudflare, AWS) to bypass IP-based blocking, necessitating additional fingerprinting of request patterns beyond source addresses.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Laurent Minne – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
