How I got here.
Seven years inside offensive security. From a cybersecurity intern in Karachi to Attack Automation Engineer on IBM's Randori HOC team in Dublin. The longer story is below - happy to bore you with the details.

I've spent 6+ years learning how attackers think - and the last few years building the systems that think like them automatically. From a cybersecurity intern at Kore Digital in Karachi, through a Master's in Cybersecurity at the National College of Ireland (1:1 honours, Dean's List), to my current role as Attack Automation Engineer on IBM's Randori HOC team in Dublin.
At IBM I develop adversary simulation platforms that replicate real-world attack techniques at scale - Python-based offensive automation, IBM X-Force threat intelligence woven into live attack routines, and containerised environments across Docker, Kubernetes, and VMware.
Before IBM, I spent 1.5 years at ML Labs running 150+ pentests - averaging 50 critical-vulnerability remediations per quarter, building toolchains that cut cycle time by 25%, and mentoring junior testers on methodology and reporting.
If you're building adversarial-simulation infrastructure or pushing the boundaries of automated red teaming, I'd like to talk.
The tools in the kit.
Offensive
Engineering
From Karachi to Dublin - the long way.
I write the Python that turns adversary tradecraft into something a customer can run on a Tuesday afternoon. The job is half threat intel - what are attackers actually doing this quarter? - and half engineering discipline: how do we ship it without breaking 200 customer environments? Some weeks I’m tracing TCP flags in Wireshark; others I’m chasing a Jenkins pipeline that won’t cooperate with Kubernetes. The good days end with a clean MITRE map and a reproducible exploit chain. The hard days end with a long Slack thread and a fresh nuclei template.
150+ engagements taught me what 15 don’t: how to triage findings honestly, how to write a report a developer will actually read, and when to stop testing because the next finding wasn’t going to change the conversation. By the end I was running engagements solo, mentoring five juniors, and shipping toolchain improvements that cut our cycle time by a quarter. Also: my first conference talk, my first time saying “no, that severity is wrong” to a senior in the room, and the engagement that finally taught me to love writing reports.
A masters that took me through cryptography, forensics, malware analysis, and IT law - but the part that mattered most was the capstone. I spent six months auditing the security of EV charging infrastructure. OCPP, ISO 15118, the back-office systems nobody thinks about. The thesis became my first piece of original research, and made the difference between “knowing how attacks work” and “knowing how attacks form.” My supervisor, Dr Arghir-Nicolae Moldovan, has my respect for the rest of my career.
My second tour at Kore. Between OWASP audits I wrote enough Python and PowerShell to cut our manual workload in half - log triage, scan automation, dashboards leadership actually used. I also wrote runbooks the team kept running long after I left for Ireland. Most days felt like detective work: a weird DNS pattern at 3am, a stored procedure doing something it shouldn’t, a developer who needed thirty minutes of patient explanation about why parameterised queries matter.
Two and a half years designing database architectures that didn’t bleed SQL injection. Lots of pair-programming with backend engineers. Lots of Kali Linux on the lab network. Lots of "please, for the love of all things holy, don’t put credentials in stored procedures" conversations. I also ran the team’s recurring security training, which is where I figured out that security is mostly a teaching job that occasionally involves exploits.
Where it all started. A four-month internship configuring firewalls and tuning Snort rules under a senior engineer who eventually became a friend. I wrote my first incident-response runbook here. The team kept using it for years after I’d moved on, which was the first time I realised that good documentation outlasts the person who wrote it.
Software development, data structures, DBMS, systems design - the foundations. I was Creative Director of the Youth Entrepreneurs Club, which is where I first learned that explaining a thing well is half the engineering. Spent a lot of late nights in the lab, broke a lot of things, fixed most of them.
Recommendations live on my LinkedIn.
Managers and colleagues I've worked with have left recommendations on my LinkedIn. I keep them there so you can see who's vouching, read it in their own words, and verify it's genuine. Detailed references are available on request.