-
-
project dashboard when attacker is detected,honeypot will be sent now, under 2 seconds remaining until we switch to mutated server node
-
project dashboard when no attacker detected,21 seconds remaining until we switch to mutated server node
-
Intrusion / Possible attacker detection seen from the server logs
-
Attacker script logs in server, it realises that it has received honeypot(fake data) and it will try to attack again now
-
The system generated a brand-new mutated backend . All API routes were rewritten to new random versions, active server file was regenerated
-
server logs for the system seen through render.com dashboard , and the system UI itself which is deployed, both side by side in this picture
The live deployed project link:- https://testing-chameleon.onrender.com/ The project server in my free trial of render.com takes 1 minute to wake up after very long periods of inactivity, you have to wait 1 minute in that case
Inspiration
Traditional servers are predictable: the same URLs, the same routes, the same attack surface every second of the day. Hackers exploit this predictability by scanning, mapping, and repeatedly probing the same endpoints until something breaks.
I wanted to explore a different idea: what if the backend didn’t stay still? What if it constantly changed shape, confused attackers, and wasted their time?
That concept — a self-mutating, deceptive backend — became the inspiration for CHAMELEON.
What it does
CHAMELEON is a self-rewriting security system that protects APIs using two core strategies:
- Moving Target Defense
The server changes its API routes every 25 seconds, automatically rewriting and regenerating the backend so attackers can’t rely on old or scanned endpoints.
- Honeypot Deception
If someone tries using an outdated or suspicious route, CHAMELEON silently diverts them to a fake decoy system that returns believable—but completely harmless—data. Real users see the real system. Attackers land in a trap.
The dashboard visually shows:
which backend node is currently active
the countdown to the next mutation
when an attack attempt is detected
when the honeypot is activated
It feels like watching a defense system that moves, reacts, and fights back.
How I built it
CHAMELEON is built as a multi-component distributed system:
A FastAPI template serves as the clean baseline for all legitimate routes.
A Python AST mutator rewrites every API path with randomized strings and generates a brand-new backend file each cycle.
Two backend nodes run side-by-side, and a proxy server routes traffic to whichever node is currently active.
A hacker-bot simulator performs replay attacks so the system can demonstrate its defensive behavior in real time.
A Streamlit dashboard display node rotation, mutation timers, replay attempts, and honeypot activations visually.
A central startup script orchestrates all components and ensures everything launches in the right order.
All of these combine into a backend that never stays the same.
Challenges I ran into
- Synchronizing live mutations
Rewriting API routes while servers are actively running is difficult. Both backend nodes, the proxy, and the dashboard had to stay perfectly aligned during every mutation cycle.
- Cloud environment restrictions
Platforms like Render only allow writing to certain directories. Building a mutation engine that works both locally and in the cloud required careful handling of file paths and atomic writes.
- Avoiding race conditions
Fast mutations can overlap with ongoing requests. The system had to be structured so that rewrites didn’t break live traffic.
- Designing the deception layer
The honeypot needed to look convincing to automated attackers, while still being completely safe and isolated.
What I learned
This project taught me how real cyberattacks happen—not through movie-style hacking, but through persistence and predictability. I learned how to build a backend that actively resists those patterns instead of waiting for a firewall to respond.
I gained deep experience with:
AST manipulation
FastAPI internals
multi-service orchestration
cloud deployment behaviors
concurrency and timing issues
Working with a system that intentionally mutates also forced me to understand file systems, process management, restarts, and how to keep everything stable while it's constantly changing.
Most importantly, I learned to think like both the attacker and the defender, which completely changed how I view backend security.
What’s next for the Chameleon Defense System
- Machine-Learning-Driven Mutation
Instead of random strings, routes could mutate based on attacker patterns and predicted threat behavior.
- Fully Distributed Multi-Node Grid
Scaling from two backend nodes to an entire rotating cluster for significantly stronger unpredictability.
- API-Level Behavior Fingerprinting
Detecting suspicious patterns like unusual request frequency, device signatures, or timing anomalies.
- Smarter, Adaptive Honeypots
Dynamic fake environments that evolve based on how attackers interact.
- Automatic Incident Reports
Auto-generated summaries of attacks, replay attempts, and honeypot triggers for security teams.
CHAMELEON already shifts the attack surface constantly, but the long-term vision is a self-adapting defense system that evolves intelligently without manual intervention.
Log in or sign up for Devpost to join the conversation.