EXPLORE MY WORK
$~: ls projects/
Security research on Named Data Networking, a live penetration test, and tools built to understand how attacks actually work.
More code on github.com/Lakshitha-01
Security research on Named Data Networking, a live penetration test, and tools built to understand how attacks actually work.
More code on github.com/Lakshitha-01
Adaptive Multi-Layer Defence Framework for Named Data Networking
Named Data Networking has two attacks that get studied constantly — and always separately. An Interest Flooding Attack (IFA) floods the Pending Interest Table with bogus requests until routers choke on state they can't resolve. A Cache Poisoning Attack (CPA) injects malicious content into router caches so legitimate requests get served garbage. Every existing defense picks one and solves it in isolation.
That's the gap AMLD-NDN targets: what happens when an attacker chains them. Degrade the router with an IFA first, then walk a poisoned cache entry through the window that opens up while the router's still recovering. Nobody in the literature models that interaction — every defense assumes it's fighting one attack at a time, which means every defense has a blind spot exactly where a real attacker would look.
The framework runs two detectors in parallel rather than trying to build one model that catches both. XGBoost handles IFA classification, trained on PIT-level traffic features — satisfaction ratio, PIT occupancy rate, nonce uniqueness, interest arrival rate. Cache poisoning gets Isolation Forest instead, unsupervised, because labelled poisoning data barely exists and building a detector that depends on it would've been solving a fake version of the problem. Both feed into an adaptive decision engine that fuses the two signals into a single threat score, classifies the network state as low, medium, or high threat, and triggers a response accordingly — PIT rate limiting, selective cache eviction, or a forwarding strategy adjustment, depending on what's actually happening rather than a fixed rule.
Evaluation runs in SimPy, benchmarked against no-defense baselines and the existing single-attack defenses, under both isolated and combined attack scenarios — which, as far as the literature I reviewed goes, makes this the first systematic comparison of defense performance specifically under the chained IFA → CPA threat model rather than either attack alone.
Chained IFA + CPA scenario, with no defense vs AMLD-NDN. SimPy simulation.
Paper (in preparation): Adaptive Multi-Layer Defense Against Chained Interest Flooding and Cache Poisoning Attacks in Named Data Networking
First author · with Dr. Rosebell Paul
Researching a structural inefficiency in Named Data Networking (NDN) that gets worse as IoT deployments scale, and proposing a fix.
NDN routes on content names instead of host addresses, which means every router maintains three core tables — the Forwarding Information Base (FIB), Pending Interest Table (PIT), and Content Store (CS) — all indexed by name. That works fine when names are short. It doesn't when they're not. In dense IoT deployments with long, hierarchical, application-defined names, all three tables balloon, and every one of them sits on memory-constrained edge routers. Existing work treats this as three separate problems: one scheme optimizes FIB naming and explicitly punts on CS and PIT, another handles CS-level caching but ignores the other two tables entirely. Nobody's solved it as one problem.
That's the gap: HASNC-NDN (Hierarchical Abbreviated Shared Naming and Caching for NDN) — a unified, token-based name compression scheme applied consistently across the FIB, PIT, and CS, so all three tables shrink together instead of being optimized in isolation. On top of the compression, I built in priority-aware naming — encoding urgency directly into the name itself (EMRG vs RTN) — so routers can distinguish and treat time-critical traffic differently without needing to inspect payload.
I evaluated the design against a hospital-ward IoT scenario — continuous per-patient vital-sign streams are a good stress test for name volume and urgency differentiation — but that's the benchmark, not the point. The contribution is the compression scheme itself; the hospital setting is just where I proved it holds up.
Measured in ndnSIM 2.9 on a healthcare IoT edge topology, against Vanilla NDN, INF-NDN IoT, LRU and FIFO.
Paper (submitted): Hierarchical Abbreviated Shared Naming and Caching for Named Data Networking in Healthcare IoT
Cyber Lumen
I got here through an international CTF competition for women in cybersecurity. I placed 2nd, which came with a full scholarship: three months of offensive cybersecurity training, fully online, hosted by RALFKAIROS, SEOUL.
The program was an equal mix of theory and hands-on practice on attack methodology and the OWASP Top 10 backed by a live Vulnerability Assessment and Pentesting against a real target and not a sandboxed CTF instance. Recon, enumeration, exploitation, and reporting, the way it actually runs on the job. My findings ranged from the classic web app issues such as missing HTTP security headers, cookies without Secure/HttpOnly flags, to more interesting ones like a Slowloris DoS vector and a clickjacking flaw from a missing X-Frame-Options header. Nothing that makes headlines on its own, but exactly the kind of chain that turns "minor hygiene issue" into "actual attack path" when you start combining them.
The harder part wasn't the exploitation…it was the reporting. CVSS scoring, clear reproduction steps, remediation guidance a dev team can actually perform without a security background. That's the deliverable that matters in a real engagement, and it's a different skill from finding the bug in the first place.
We also spent the back half of the program prepping for CEH, because three months of full-time offensive security apparently wasn't quite enough on its own.
Thanks to Julien Provenzano, my mentor without whom this would not have been possible. One of the best takeaways from him has been the mindset that every problem has a solution.
What I took away from it wasn't a certificate. It was a shift in how I think about security. Less "here are the rules," more "everything has edges, and edges are just places someone didn't finish thinking through."
Python · Flask · ngrok
Built to demonstrate how phishing actually works end-to-end with not just the email, but the full attack chain a target experiences, for cybersecurity awareness training in a controlled environment.
It's a Flask app that walks through the same flow a real campaign would: pick an email template, customize the content, choose a landing page and brand context, preview the generated email, then send it via SMTP. Click the link, land on a page built to look legitimate, and whatever gets submitted is logged locally for review afterward. Dynamic routing handles the landing pages, Jinja templates handle the customization, and the whole thing runs behind ngrok so it can be tested against a real public URL instead of just localhost, which matters because a phishing sim that only works on your own machine doesn't tell you anything useful now does it.
I also packaged it with PyInstaller into a standalone executable, mainly so it could be handed off and run without someone needing a Python environment set up first.
The honest takeaway: technical controls only get you so far. Firewalls, patched software, hardened configs…none of it matters if someone clicks the wrong link at 5pm on a Friday. Building this made that concrete instead of theoretical.
ESP32 · R307 fingerprint sensor · Team of six
Car keys have been the weakest link in vehicle security for decades. They get lost, copied, or skipped entirely by someone with a screwdriver and a bit of hot-wiring knowledge. We built a cyber-physical ignition system that replaces the key with the one thing you can't misplace in your other jacket: your fingerprint. A team project of six, built over a semester for the Design Thinking and Innovation course.
It runs on an ESP32 with an R307 fingerprint sensor. You enrol a finger by scanning it twice, the sensor builds a template from the two images and stores it, and from then on every scan is matched against the stored templates. A match flips a relay that powers the ignition, and an OLED screen says Access Granted or Access Denied so you're never guessing what the system decided. A 4x4 keypad handles enrolment, navigation and a PIN fallback, because a fingerprint reader that locks you out of your own car on a rainy day isn't much of a security feature. For the demo, the relay powers an LED bulb that stands in for the ignition.
The testing was the fun part. We fed it borderline and partial fingerprints to check it wouldn't wave through something close enough, repeated scan cycles to see if it held up over time, switched the relay rapidly to see how the hardware handled it, and ran it off a USB power bank to see what happened when the power wasn't clean. After five failed attempts, the buzzer goes off.
The honest takeaway: biometrics only solve half the problem. The fingerprint can't be copied like a key, but a system is only as strong as its weakest way in, so the fallback path had to be treated as an attack surface from day one instead of an afterthought.