Essay · Just for fun

Fighting a Phishing Site

Reverse-engineering a bank phishing site targeting Irish customers, then drowning its stolen-credentials database in 4,000 fakes.

In early 2022, a phishing site appeared targeting customers of AIB, one of Ireland's largest banks. The fake site was well-built and surprisingly clever about who it showed itself to. Rather than report it and move on, I decided to fight back.

The scam

The site sat at aib.ie1.online, a domain close enough to fool someone clicking a link in a hurry. Visit from a desktop browser and it returned a blank 404. Nothing to see. Visit from a mobile phone and it displayed a convincing replica of the AIB login page.

The trick was the User-Agent header, a label every browser automatically sends to identify itself. Desktop browsers send one kind; mobile browsers send another. The scammers filtered on this to avoid detection. Desktop visitors, likely security researchers or bank staff checking reports, saw nothing. Mobile visitors, more likely to be real customers tapping a link from a text, saw the trap. The fake form asked for an AIB registration number (an eight-digit account identifier) and a PAC code (a five-digit access code). Anyone who entered their real details handed them straight to the scammers.

Understanding the target

To build a convincing counter-attack, I first needed to know exactly what the site was checking. I scraped hundreds of real mobile User-Agent strings from whatismybrowser.com, a public database of browser signatures, giving me genuine Android and iOS identifiers to work with.

Inspecting the login form revealed the endpoint: a file at /files/action.php?type=login that accepted four fields. Alongside the registration number and PAC code, the site logged each visitor's IP address and User-Agent. The IP logging was probably defensive. If a security org or law enforcement started probing, the scammers could block those addresses. So any effective counter-attack had to come from IPs that looked like ordinary Irish broadband connections.

Building the ammunition

The counter-attack needed three ingredients:

Fake but plausible credentials. Registration numbers are eight digits, so I generated random numbers between 10,000,000 and 99,999,999; PAC codes are five digits, drawn between 10,000 and 99,999. None matched real accounts, but they looked exactly like the genuine article.
Irish IP addresses. I scraped a table of real Irish IP ranges from nirsoft.net, then shifted each segment by a small random amount to produce plausible addresses that still traced back to Ireland, traffic that looked like ordinary Irish broadband.
A realistic browser mix. In Europe, roughly 72% of mobile traffic is Android and 28% iPhone. I matched that ratio when picking User-Agents, so the submissions looked like a normal cross-section of Irish mobile users.

The counter-attack

With everything in place, I sent 4,000 POST requests to the scammer's login endpoint. Each carried a unique combination of randomised fake credentials, a spoofed Irish IP, and a real mobile User-Agent. One more detail: a 24% chance that each submission would be resent immediately. The site answered every attempt with an "incorrect credentials" message, clearly designed to make confused victims re-enter their details, so mimicking that re-entry pattern made the fakes harder to tell apart from the real thing.

The result: for every genuine victim who fell for the site, the scammers' database now held roughly 200 fake entries. Finding a real registration number and PAC code in that noise would take longer than the data was worth. The stolen credentials were effectively poisoned.

Sometimes the most useful thing you can do with a technical skill is notice something that feels wrong and act on it.