I trace the attack path.

From my VNCS internship — full role summary in Experience.

Stood up Splunk Enterprise as a distributed deployment — a Deployment Server pushing config to universal forwarders across mixed hosts — then brought several log families into one searchable surface: Windows Event Log, Sysmon, Linux syslog, web application logs and firewall/syslog feeds.

Onboarding the data was the bulk of it: field extraction written by hand in transforms.conf with regex where the shipped add-ons mis-parsed, custom sourcetypes for the feeds no add-on covered, and everything normalised against the Splunk Common Information Model so a field means the same thing no matter which host it came from.

Then the work that made it useful: confirming events actually arrived, correcting extraction where sourcetypes mis-parsed, normalising time before anything was trusted, and building the reports, dashboards and alerts — routed to email and chat — that somebody would actually act on.

Scroll the diagram sideways to see all of it.

1. Collect
2. Parse
3. Normalise
4. Validate

Stack

Splunk Enterprise, Deployment Server, Forwarder Management, Universal Forwarders

Parsing

Hand-written transforms.conf extraction, regex, custom sourcetypes, Splunk CIM

Sources

Windows Event, Sysmon, Linux, Oracle, firewall

Output

Dashboards, reports, alerts routed to email and chat

What it demonstrates Detection is downstream of data quality. The onboarding work — sourcetypes, extraction, time — is what decides whether the alert fires on the right thing. Normalising to CIM is what makes a search written once keep working when the next log source lands.

From my VNPRO internship — full role summary in Experience.

I was interning on the network side, not in security. When an external bug hunter reported two serious flaws in an internal admin panel, I asked the company for permission to work on it, got approval, and only then started testing.

The first two were a SQL injection that bypassed admin login outright, and an HTTP verb tampering flaw that escalated privileges — the authorisation check was written against GET while the application read its parameters from $_REQUEST, so changing the request method walked straight past it. The third I found myself: the dashboard echoed the raw username back into the page instead of reading it from the database, which turned a logic mistake into a reflected XSS vector.

I also worked out that a far smaller payload than the original report used was enough to get in, and documented why — the login logic depended entirely on what the user typed, with nothing behind it.

1. Reproduce
2. Root cause
3. Fix
4. Re-test

Found

SQL injection (auth bypass) · HTTP verb tampering (privilege escalation) · reflected XSS

Fixed

Input sanitisation, removal of legacy default-password logic, explicit role checks, output encoding, method-pinned parameters, .htaccess hardening

Verified

Re-tested after deploying to production — 3 of 4 items closed, the remainder documented rather than dropped

Rule

Written authorisation before testing, sanitised before publishing

What it demonstrates That I can read the code that caused the flaw, not just run the tool that found it — and that I know to ask permission first.