I Built a Fake Login Page to Get Hacked on Purpose

Here’s What I Learned About Detection Engineering…

Most beginner cybersecurity projects analyze data someone else already collected — a sample malware hash, a pre-made PCAP file, a CSV of “suspicious” logins. I wanted to build something that generated its own evidence: a real target, real attack traffic, and detection logic I had to write and prove actually worked.

So I built a honeypot.

The Idea

A honeypot is a system designed to look like a real target, but it’s not connected to anything valuable, and its only job is to watch and record what happens to it. Mine was simple: a fake login page. No real accounts, no real database, no way to actually “log in.” Every single submission — real-looking or malicious would just get written to a log file.

The real project wasn’t the login page. It was everything downstream of it.

Building the Target

The login page itself was plain HTML/CSS — nothing fancy, just something that looked like a normal sign-in form.

The interesting part was the backend, built in Python with Flask. Every time someone submitted the form, the server captured:

• Timestamp
• IP address
• Username and password (exactly as typed, no validation)
• User agent (browser/device info)

It wrote it as structured JSON to a log file. The page never gave any feedback — no “wrong password,” no “success.” It just quietly logged and reloaded. That’s the core honeypot principle: never tip off the attacker that you’re watching.

Attacking My Own Server

To make this realistic, I didn’t just click the form myself a few times. I set up a separate Kali Linux VM, networked it to talk to my Flask server, and used it to run actual attacker tooling against my own honeypot:

• Manual injection attempts — classic payloads like admin' -- (SQL injection) and <script>alert(1)</script> (XSS), typed directly into the login form
• Automated brute-forcing with Hydra — a real password-cracking tool, run against a 500-entry password wordlist, hammering the login endpoint with admin + hundreds of guessed passwords in seconds

Getting the two machines talking to each other was its own small adventure — wrong network adapters, a stray VirtualBox IP left over from a previous install, Windows Firewall silently swallowing every request. Every “it’s not working” turned out to be one specific, fixable thing. That troubleshooting loop is honestly a big part of what this project taught me.

From Logs to Detection

Once the attacks were logged, I had 511 events sitting in a JSON log file. Raw logs aren’t useful on their own — the whole point of a SOC analyst’s job is turning that into signal. So I brought the log into Splunk and started writing detection queries.

Catching the brute-force pattern:

sourcetype="honeypot_json" | bucket _time span=5m | stats count by ip, _time | where count > 10

This groups events into 5-minute windows and flags any IP that crosses 10 attempts within one window. Run against my data, it isolated exactly one result: my Kali VM’s IP, with 500 attempts in a single 5-minute window. No noise, no false positives.

Classifying every event automatically:

sourcetype="honeypot_json" | eval attack_type=case(match(password, "'|--"), "SQLi", match(password, "<script>"), "XSS", 1=1, "Brute Force/Other") | stats count by attack_type

This tagged every single event with a category, rather than just detecting one pattern at a time — closer to how real classification pipelines work.

I pulled these together into a single Splunk dashboard so all detections and a timeline visualization live in one view.

What This Actually Taught Me

The technical skills are the obvious part: Flask, JSON logging, cross-VM networking, Splunk Search Processing Language. But the bigger lesson was about thinking like an analyst rather than just running tools. Anyone can run Hydra. The actual work is asking: how do I tell the difference between one attacker and normal traffic, using nothing but timestamps and a few fields? That’s the question every real detection rule is answering.

I also learned that a huge percentage of security work is mundane troubleshooting — firewall rules, network adapters, file permissions — long before you get to the “interesting” analyst part. That’s not a glamorous lesson, but it’s a real one.

What’s Next

A few directions I want to take this further:

• Splunk alerting (my current setup uses the Free license, which doesn’t support scheduled alerts)
• Expanding the attack surface (command injection, path traversal payloads)
• Automating the log transfer from target to SIEM instead of doing it manually

If you’re getting into SOC/security work and every project you’ve done has been “analyze this dataset someone gave you,” I’d genuinely recommend building something like this instead. Owning the entire pipeline — target, attack, log, detection — teaches you more than any pre-packaged lab ever will.

Full project writeup and code: [https://github.com/Ziah19/Honeypot-Web-App-Log-Pipeline]

Faaiziat Akanni