OpSec Fail: A Simple HTTP Server Exposes 3 Evilginx Campaigns
Just saw the report from Lexfo regarding the misconfigured server. It’s almost poetic how these massive phishing campaigns get taken down—not by 0-days, but by basic OpSec failures. The operator was running an M365 phishing kit (likely Evilginx2) and left a Python HTTP server exposed on port 8080 with directory listing enabled.
The smoking gun? The command python3 -m http.server 8080 was sitting right there in the readable .bash_history. Lexfo grabbed the toolkit and pivoted to two other operations.
We often focus on the phishing sites themselves, but the backend infrastructure is where the real intelligence lives. If you're hunting for these proxies or C2s, look for unexpected directory listings on high ports.
Here's a quick check for your perimeter scanning tools to catch similar boneheaded configs:
nmap
nmap -p 8000-9000 --script http-enum
Or if you're combing through logs for Python servers on non-standard ports:
DeviceNetworkEvents
| where RemotePort in (8080, 8000, 3000)
| where ProcessName contains "python"
It’s a reminder that strict user permissions and history logging matter for attackers too.
**Question:** What's the worst OpSec fail you've seen during an incident response or a pentest that gave away the whole game?
It's crazy how often basic hygiene issues break the chain. We use Atomic Red Team tests to simulate these exact misconfigurations internally. Don't forget to also scan for exposed .git directories or backup files like index.php.bak—I've found full credentials in those more times than I can count.
Evilginx is nasty because it bypasses MFA, so catching the infrastructure is crucial. The directory listing here is amateur hour. I once found a full APT playbook because they left an SMB share open with 'Everyone/Full Control' permissions. Always check the simple stuff before diving into complex malware analysis.
As a sysadmin, I've actually blocked the execution of python3 -m http.server on our jump servers unless it's inside a specific container. It's too easy for devs or admins to spin up a quick file share and forget it's listening on 0.0.0.0. Automation usually catches these, but only if you're actually looking for port 8080 traffic.
This is a great reminder that default logging settings can be your enemy. Beyond just blocking the execution, ensure your bash configuration ignores sensitive commands or limits history size. You can add this to .bashrc to prevent specific commands from ever hitting the disk:
export HISTIGNORE="*python3 -m http.server*:*password*"
It’s a small line of defense, but it stops the smoking gun from sitting in plain text.
While hygiene is key, network telemetry can catch these setups before errors do. Hunting for specific Evilginx JARM hashes in your SIEM is effective since default TLS signatures are distinct. This often reveals reverse proxies that aren't exposing file listings.
DeviceNetworkEvents
| where RemotePort == 443
| where JARM == "07d3...specific_hash..."
| distinct DeviceName, RemoteUrl
Has anyone automated JARM fingerprinting for internal phishing kits, or are you mostly relying on ETW/PowerShell logging?
Spot on analysis. From an IR standpoint, .bash_history is often the smoking gun that reveals intent even when logs are sparse. While Tyler mentioned sanitization, a quick mitigation for your own team is adding HISTCONTROL=ignorespace to global profiles—adding a space before a command prevents it from being logged entirely.
echo 'export HISTCONTROL=ignorespace' >> /etc/profile
Automating the hunt for these exposed directory listings with Nuclei templates is also a solid preventative measure.
To catch this proactively, focus on the process execution logs. Spotting specific CLI arguments helps differentiate legitimate dev work from phishing kits. A quick KQL query in your SIEM looking for the standard Python module can alert you instantly.
Process where process_name == "python3" and process_command_line contains "http.server"
Active discovery is often overlooked in favor of config hardening. We run regular internal sweeps for open high ports to catch these ad-hoc servers before they are abused. A quick nmap sweep across the subnet usually reveals forgotten instances listening on 0.0.0.0:
nmap -p 8000-9000 --open 10.0.0.0/24
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access