Anatomy of a South African Bank Phishing Attack

This investigation reconstructed a multi-stage phishing flow that combined a cloned banking interface, credential theft, collection of card and phone details, and social engineering around one-time authentication.

Original investigation: February 2024

Article type: Security investigation

Executive summary

This investigation examined a phishing campaign targeting customers of a South African bank. I have kept the bank anonymised here because the technical lessons are more important than the brand.

At the time of the research, the attack used several pieces of distributed infrastructure rather than one obvious phishing server.

The observed flow appeared to include:

1. a cloned banking page hosted through third-party infrastructure;

2. collection of online-banking credentials;

3. collection of a mobile number and payment-card information;

4. submission of those details to a separate backend domain; and

5. a follow-up social-engineering call intended to obtain or influence the victim's use of a one-time authentication code.

The attack illustrates why phishing defence cannot depend only on spotting a badly designed fake website.

The initial phishing layer

The first page imitated elements of the bank's online-banking interface.

At the time of the investigation, part of the content was hosted through a third-party storage or hosting environment with valid HTTPS for the provider's own domain.

This is an important distinction:

A valid TLS/SSL certificate means the connection to the domain is encrypted. It does not prove that the content or business behind the page is legitimate.

Attackers can host malicious content on legitimate infrastructure and still present a browser with a valid encrypted connection.

Credential collection

The phishing form appeared designed to collect online-banking credentials and submit them to backend processing hosted elsewhere.

The sequence then requested additional information including a telephone number and card details.

The form's validation was not sophisticated. That is common in phishing infrastructure because the attacker does not need to recreate the bank's full application. The objective is simply to collect enough useful data to progress the attack.

The second stage: social engineering

The more concerning part of the campaign was the apparent combination of web phishing with a telephone call.

Once credentials are captured, an attacker can attempt to use them against the genuine banking service. If the bank triggers an additional authentication step, the attacker must persuade the victim to cooperate.

A call pretending to come from the bank can provide that bridge.

The victim may be told that:

• a suspicious transaction is being cancelled;

• a security verification is required;

• an authentication prompt must be approved; or

• a one-time code must be read back.

In reality, the authentication action may authorise the attacker.

This is why authentication messages must describe the action being approved as clearly as possible.

Why trusted communication channels matter

Banks legitimately call their customers. Attackers know this.

If a bank's normal support process relies heavily on unsolicited calls, customers face a difficult identity problem: how do I know this is really the bank?

The safer pattern is to allow the customer to move the interaction into a channel they can independently authenticate, such as the bank's official application or a number obtained from a known source.

A customer should never have to rely on caller ID or the caller's knowledge of personal details as proof of identity.

Infrastructure observed during the investigation

The original research identified multiple service providers associated with different stages of the attack, including hosting, domain-registration and backend-processing services in different countries.

Those findings were useful for abuse reporting because each provider controlled a different part of the attack chain.

However, hosting location and registrar location do not establish where the criminal operators themselves were located.

How organisations should respond to active phishing infrastructure

When a bank becomes aware of an active campaign, response should be coordinated and evidence-driven.

Preserve evidence

Capture the phishing pages, URLs, form actions, DNS records, timestamps, screenshots, email or SMS messages and relevant headers.

Map the full chain

Identify every domain and provider involved in:

• initial delivery;

• page hosting;

• credential submission;

• payment collection;

• redirects;

• email; and

• DNS.

Report at each control point

Submit abuse reports to registrars, hosts, storage providers, DNS/CDN providers, payment organisations and search or messaging platforms where relevant.

Warn customers

Provide clear examples of the active attack and tell customers exactly how legitimate security interactions are conducted.

Review authentication design

Determine whether attackers are exploiting confusing prompts, weak authentication, insecure recovery flows or ambiguous customer communication.

Questions raised by targeted phishing

A recurring question in targeted fraud is how attackers know which people to approach.

Possible sources include:

• broad spam campaigns;

• previous data breaches;

• compromised marketing lists;

• publicly available information;

• information stolen from another service;

• malware or account compromise; or

• in some cases, insider access.

The presence of accurate personal information does not by itself prove that the data came from the bank. Attribution requires evidence about the source of the data.

Security lessons for banks

1. Make customer authentication unambiguous

Authentication prompts should state clearly what the customer is approving.

2. Give customers a trusted callback path

A customer who receives a suspicious call should be able to terminate it and re-establish contact through a verified channel without losing the case context.

3. Separate marketing from security messaging

Security channels should not be diluted with commercial communication that trains customers to ignore or casually approve messages.

4. Operate a rapid phishing-takedown capability

Known malicious domains should trigger an established incident workflow rather than ad hoc reporting.

5. Measure the attack pattern

Track which domains, brands, customer segments, authentication steps and communication channels attackers repeatedly exploit.

Security lessons for customers

• Do not log into banking through a link in an unexpected message.

• Do not disclose a password or one-time code to a caller.

• Read authentication prompts carefully.

• End suspicious calls and contact the bank through a known channel.

• Report the exact URL used in the attack.

• Preserve evidence before deleting messages or browser history.

Conclusion

This campaign was effective because it combined several ordinary components into one attack journey: a convincing page, legitimate third-party infrastructure, stolen credentials, additional personal information and a telephone call.

The lesson is broader than one bank.

Phishing defence has to protect the entire customer interaction, not just the login page.

Banks need trustworthy communication channels, clear authentication prompts and fast infrastructure takedown. Customers need a simple way to verify that a security interaction is genuine before they approve anything.