It Started With an Email
Subject: “Congratulations! You've Just Won ₦750,000 in the Dangote Empowerment Grant!”
I almost laughed when I saw it in my inbox. The email had all the usual red flags: questionable grammar, a blurry logo, and a sense of urgency that felt manufactured. It was the kind of thing most people would delete without a second thought. But I was curious. As a cybersecurity analyst based in Lagos, Nigeria, these kinds of scams were textbook.
I didn’t open it to fall for it. I opened it to analyze it. Just to inspect the headers. Just to examine the phishing structure. Just to see how lazy the attacker was.
The link inside looked like a Google Docs form, rebranded to look like an official grant registration portal. I clicked it from a hardened browser I use strictly for sandbox testing. Nothing loaded. Just a white screen. I closed the tab and went on with my day.
Three days later, I got an alert on my PalmPay wallet.
₦4,500 had been withdrawn. Sent to a merchant I didn’t recognize.
I froze. I knew I hadn’t made any transactions. I hadn’t authorized anything. The name of the receiving merchant was a funny Hausa name. I did a reverse search on the name and found nothing.
A quick log-in confirmed my fear: someone had accessed my wallet. I dug into the account logs and saw that a Betting API had been authorized earlier that day from an IP address in Lagos.
Still unsure of how it happened, I retraced my steps. Then it hit me.
That email.
The fake Dangote grant.
I never submitted any personal information. I didn’t type a password or confirm any OTP. So how had they gotten access?
What they used was a silent redirect technique. The phishing link didn’t just take me to a fake form; it hijacked my session token. Because I had accessed PalmPay on that same browser a day before and hadn’t logged out, the attacker used that vulnerability to intercept the active token.
Before I continue my story, let's talk about the “Silent Redirect Technique.”
Silent redirect is one of those sneaky tricks hackers use to steal from people without them ever knowing what hit them. Unlike the traditional phishing scams that scream danger with poorly written emails and obvious fake websites, silent redirect works in the shadows. It’s like someone inviting you into a room, and without your knowledge, secretly copying the key to your front door while you’re inside. It’s smooth, quiet, and very dangerous.
At its core, silent redirect takes advantage of how websites and browsers handle sessions. When you log in to apps like your bank, your wallet, or your email, they give your browser a session token. This token is like a VIP pass that says, “This person is logged in, let them do whatever they want without asking for a password again.” As long as that token is valid, the site trusts you.
Now, imagine if someone else got access to that token without needing your password. That’s exactly what silent redirect aims to do.
Here’s how it usually plays out. You get a legit-looking email. It might say you’ve won something, or that your account has a security issue. Nothing alarming, just a polite message with a link. You click on it, and it takes you to what looks like a blank page or a loading screen.
You don’t see anything suspicious, so you close the tab and forget about it. What you don’t know is that the link quietly redirected your browser in the background to another site controlled by the attacker. This hidden site doesn't ask you to enter anything, but it does something worse: it silently steals your active session.
Let’s say you had logged into your mobile wallet or banking app earlier on that same browser. If you didn’t log out properly, the attacker’s script can use that live session to trick the real app into thinking it’s still you. Without a single password typed, the hacker now has access. That’s why it’s called a “silent” redirect because it happens without alerting you or asking for input.
The scary part is that this technique doesn’t rely on you being careless. It targets session handling, not passwords. Even tech-savvy people can fall for it if they click links casually while logged into sensitive apps.
Some versions of this attack even mimic real services, pulling in actual branding and using clever URL disguises to look clean. They can also use cross-site scripting (XSS) or third-party vulnerabilities in some websites to deliver the payload.
Back to the story…
They didn’t need my password. They used my open session against me.
I had just been breached.
And it stung more than it should have, not because of the money, but because this was supposed to be my domain. I work in cybersecurity. I build defenses. I conduct penetration tests.
I teach people how not to fall for this, and guess who fell for it.
But this wasn’t just a basic phishing attempt. This was refined. Advanced. Targeted.
And it felt personal.
I wasn’t going to let it slide.
I decided I was going to trace the hacker. I was going to dig deep, track the infrastructure, bait the attacker, and get my pound of flesh. Not just for myself, but for everyone else they had likely targeted.
What followed was a long digital manhunt, curated and documented.
This is how I hacked a hacker.
Part 2 — The Hunt.
If you enjoyed this story, consider joining our mailing list. We share real stories, guides, and curated insights on web development, cybersecurity, blockchain, and cloud computing, no spam, just content worth your time.
Top comments (0)