Template Terror: Tracking a Single Phishing Kit’s Trail Across the Banking Sector

Most phishing investigations start with a suspicious domain. This one started with a support address buried in a contact page.

In August 2026, our threat hunting team pulled on that thread and ended up with roughly 131 banking and financial services domains that all claimed to belong to different institutions. They didn’t behave like different institutions. Underneath the logos, the color palettes, and the invented bank names, the same website kept reappearing, rebranded and redeployed.

The headline here isn’t the domain count. It’s what the count implies. These sites look like repeated deployments of one reusable phishing framework, which means the operator isn’t building phishing pages so much as configuring them. When impersonating a new bank is a matter of swapping a logo and a page title, the cost of launching the next campaign collapses toward zero.

Investigation snapshot

Why banking brands stay near the top of the target list

Financial institutions attract phshing operators for an unglamorous reason: stolen banking credentials convert quickly. A working username and password can enable account takeover, identity theft, and outright financial fraud, and the same credentials often unlock the personal details that make the next round of social engineering more convincing.

That pressure is only increasing as attackers adopt generative tooling of their own. We’ve written before about how AI is changing the way banks detect fraud, and the campaign below is a useful reminder that not every scalable attack needs a large language model behind it. Sometimes a well-built template is enough.

How the cluster surfaced

The investigation began with a broader look at the IP address 57.129.85.4, where we identified hxxps://europealliancefinance[.]com. Its Contact Us section listed the email address support@sadb-pg-nimb[.]com, which gave us a second pivot point.

Analyzing sadb-pg-nimb[.]com led to the IP address 192.99.230.86, which was associated with roughly 960 domains. The banking cluster was sitting inside that much larger dataset, alongside campaigns that had nothing to do with financial services at all.

Everything here was done with passive, non-intrusive threat intelligence techniques. The goal wasn’t just to collect domains. It was to determine whether apparently independent financial websites were, in fact, deployments of a shared phishing framework.

One methodological note matters more than the rest. We deliberately built the case on multiple independent indicators instead of treating a shared IP address as proof of common ownership. Large hosting providers legitimately host unrelated customers side by side, and an analysis that ignores that produces confident conclusions that fall apart under scrutiny.

Different banks, the same website

At the domain level, these sites looked like separate organizations. Each had its own name, its own branding, and its own story about who it served. Comparing them side by side told a different story.

Recurring characteristics across the cluster included:

• Consistent page layouts
• Matching login interfaces
• Comparable typography and styling
• Repeated form structures
• Common animation patterns
• Consistent button placement
• Recurring terminology
• Comparable user interaction patterns
• Consistent deployment behavior

Any one of those overlaps could be coincidence, since phishing operators borrow freely from commercial website templates. All of them together, repeating across dozens of supposedly unrelated financial brands, is a pattern.

Look closely at the four screenshots above. Same hero image, same headline, same 13M+ and 0% statistics, same layout skeleton. The only things that really change are the name, the logo, and the color scheme.

One framework, many brand configurations

The frontend similarities point toward a reusable phishing framework in which the underlying structure stays fixed while brand-specific elements get swapped out. Instead of developing a Bank A site, a Bank B site, and a Bank C site independently, the operator maintains one implementation and a set of brand configurations.

The conceptual model looks like this:

This is the same efficiency logic that legitimate software teams apply to design systems, turned to a criminal purpose. Repeated frontend characteristics, brand variation, and multiple simultaneous deployments together make a much stronger case for a phishing kit cluster than any single indicator could on its own.

Brand impersonation becomes a configuration change

One of the more telling findings was the NIMB identifier appearing inside a banking portal on this infrastructure. The naming pattern is consistent with an attempt to reference Nepal Investment Mega Bank.

That matters because it moves the kit beyond generic banking chrome. This infrastructure can present itself as a specific, named financial institution, which is the difference between a page that looks vaguely bank-like and a page a real customer might believe.

Within a reusable kit, an operator can modify:

• Bank name
• Logo
• Domain
• Page title
• Colors
• Login text
• Institution-specific terminology

The website architecture underneath stays intact. Brand impersonation stops being a build and starts being a form field, which is exactly why detection has to look past surface-level branding. The same problem shows up with AI-generated phishing pages, where polished visuals and clean copy strip away the spelling errors and layout tells that defenders once relied on.

Infrastructure built to absorb takedowns

The banking infrastructure spans multiple IP addresses rather than concentrating on a single server.

Distribution buys the operator resilience. Block one domain or one IP, and the other deployments keep serving victims. It’s a structural argument for handling these campaigns at the cluster level rather than one URL at a time, and for compressing the window between detection and removal. Our phishing site takedown guide walks through why that window decides how much damage a campaign actually does.

The broader 960-domain footprint

The banking cluster surfaced inside a much larger dataset of roughly 960 domains associated with 192.99.230.86. That dataset was a mixture of legitimate-looking and suspicious websites, and clustering plus keyword analysis pulled out several distinct fraud categories.

Taken together, the wider footprint looks like a shared or multi-campaign fraud hosting environment. That’s useful intelligence about where fraud infrastructure clusters, and it’s a reasonable place to focus additional hunting. It is not proof that one actor runs all 960 domains.

Shared hosting is not shared attribution

This is the analytical line worth defending. Banking phishing domains, fake court websites, and USPTO renewal scams appearing in the same hosting environment does not establish that a single threat actor operates all of them.

• Multiple actors using the same hosting provider
• Reseler infrastructure
• Compromised servers
• Abuse-tolerant servers
• Independent campaigns that happen to share infrastructure
• One actor running several campaigns

So we classify the 960-domain relationship as a hosting and infrastructure correlation, and nothing more. The banking cluster earns a stronger verdict because multiple independent website characteristics correlate across those specific domains. Evidence at the website level, not IP ownership, is what carries that conclusion.

What makes this a phishing kit cluster

Five indicators, in combination, supporting the phishing kit read:

• Reusable architecture: a common underlying structure appears across multiple deployments.
• Brand substitution: different financial identities are presented through the same framework.
• Scalable deployment: roughly 131 banking-related domains indicate the ability to stand up new instances quickly.
• Operational reuse: similar deployment patterns point to a repeated development methodology.
• Infrastructure correlation: related hosting provides supporting, though not conclusive, evidence.

None of these is decisive alone. Together they describe an adaptable banking phishing kit capable of supporting many financial brand impersonation campaigns at once.

What this means for security teams

Hunt at the template level, not the domain level. If a kit produces a hundred sites, chasing each domain individually means running a hundred investigations against one adversary. Fingerprint the template instead: DOM structure, form logic, shared JavaScript and CSS, repeated asset paths, and identical copy. Continuous domain monitoring gives you the raw scanning coverage to spot the next deployment while it’s still new.

Treat visual similarity as a signal in its own right. Logo detection, page layout comparison, and image similarity catch what string matching on domain names never will, especially when the impersonated brand’s name never appears in the URL.

Assume the infrastructure is disposable and plan accordingly. Operators expect individual domains to be blocked. Removing a single URL from a cluster like this buys hours, not weeks.

Finally, keep attribution and infrastructure correlation in separate buckets. Conflating the two produces intelligence that feels satisfying and doesn’t survive contact with a skeptical stakeholder. One financial institution that made this shift cut its takedown time from months to hours largely by consolidating detection and response into a single workflow instead of treating every domain as a fresh case.

Indicators observed

Domains (defanged):

• hxxps://europealliancefinance[.]com
• hxxps://globalassetsbank[.]com
• hxxps://oldchase[.]online
• hxxps://unitystonebank[.]com
• hxxps://app.vestorly[.]live
• sadb-pg-nimb[.]com

IP addresses:

• 192.99.230.86
• 57.128.229.28
• 57.129.85.4

ASN:

• AS16276 (OVH SAS)

Email address:

• support@sadb-pg-nimb[.]com

The Takeaway

The identification of roughly 131 banking-related domains sharing recurring technical and visual characteristics is a meaningful threat intelligence finding, but the number is the least interesting part of it. What matters is the evidence that these are deployments of one common, reusable phishing framework.

That reframes the work. Instead of a domain-by-domain grind, the investigation becomes an exercise in phishing kit and infrastructure clustering, where taking apart the template does more damage to the operation than removing any individual site. The broader 960-domain footprint adds context about where this kind of fraud infrastructure lives, with the caveat that it stays an infrastructure correlation until stronger evidence says otherwise.

Whoever is behind this cluster has built something designed to scale. Defenses that only see one fake bank at a time will keep meeting the next one.

Seeing the campaign, not just the domain

Kit-based campaigns are precisely the case where domain-by-domain response falls behind. Bolster AI’s detection engine combines page structure analysis, logo detection, and visual comparison to group related deployments into a single campaign view, with our SOC analysts reviewing the edge cases that automation shouldn’t decide alone. If your team is chasing lookalike banking domains one takedown at a time, it’s worth seeing how phishing detection and takedown works when the unit of investigation is the campaign rather than the URL.