Inside Phishing Attacks: How Threat Intelligence Exposes the Infrastructure

Romano Ramanti

Zürcher Kantonalbank, Switzerland

Certified Ethical Hacker

Email filters will never stop every phishing campaign. Some messages are caught at the perimeter. Others go directly to customers through personal email accounts, text messages or external platforms. The bank may hear about the attack only when someone reports a suspicious message or, worse, after credentials have been stolen.

That is why phishing defence cannot end with the email. Security teams need to understand where the fake page is hosted, how stolen data move through the infrastructure, how the attacker is notified and where the chain can be interrupted.

Romano Ramanti, Certified Ethical Hacker at Zürcher Kantonalbank, approaches phishing as an infrastructure problem. His investigations cover cloned websites, exposed directories, databases, Telegram bots and administrative panels. These components often contain something attackers would rather not leave behind: their own operational mistakes.

A Convincing Email Can Hide a Different Technical Source

A typical phishing attack begins with a message that looks familiar. The visible sender may appear to be a bank, while the address differs from the legitimate one by only a character or two.

The technical headers can tell a different story, revealing where the message actually originated. Most customers will never inspect those fields, nor should a bank expect them to conduct a forensic examination before opening an email.

Figure 1. Example of a suspicious email

Homoglyph attacks make the deception harder to spot. A homoglyph is a character that closely resembles a letter from another alphabet. An attacker can replace one character in a legitimate domain, register the new DNS name and send messages from an address that looks genuine on screen.

The link leads to the attacker’s website, but the difference may be almost invisible.

Figure 2. Homoglyph generator replacing letters with similar characters

This technique works because people recognise shapes and brands faster than they examine spelling. A familiar logo, a plausible address and a well-copied login page are often enough to create confidence.

When the imitation is convincing, telling customers to be more careful is not an adequate defence. The security team needs to find the fraudulent infrastructure and act before the campaign reaches more people.

An Email Does Not Need a Link to Collect Information

One investigation began with an email that contained no attachment and no visible link. Nothing appeared to happen when the message was opened.

The source code told a different story. It contained invisible images measuring one pixel by one pixel.

Figure 3. Invisible tracking pixels embedded in an email

These tracking pixels were not designed to install malware. They served a quieter purpose: confirming that the recipient had opened the email.

Opening the message caused the images to load from the attacker’s server. The request confirmed that the email address was active and exposed information linked to the user’s IP address, browser and operating system.

The message was therefore part of the reconnaissance stage. Before attempting the main fraud, the attacker was checking which recipients were real, active and worth targeting.

In this case, the attackers had left their server poorly secured. An exposed directory led to a folder containing an SQL database. The database listed people who had opened the emails and included details of their browsers and systems.

Some of the recipients were customers of the bank. The discovery allowed the bank to warn them that someone might contact them while pretending to represent the institution.

Exposed infrastructure is not present in every campaign, and investigators cannot assume that it will be. But attackers work quickly and make mistakes. The faster a security team can interpret the evidence, the sooner it can reduce the period during which customers remain exposed.

Follow the Chain, Not Just the Fake Website

A second investigation involved a more elaborate campaign.

Customers received an email claiming that the bank was changing its login procedure. The message asked them to follow a link, reactivate their account and apply for a special product. The sender’s address did not belong to the bank, but the story was plausible enough to catch an inattentive recipient.

The link opened a cloned version of the bank’s online banking page. Users were first asked for their login credentials and then for a code from a genuine activation email sent by the bank. Once both had been captured, the attacker could take control of the account.

Finding the fraudulent website was only the beginning. Investigators needed to determine where the credentials were sent, which systems processed them and how the attacker knew that a new victim had entered information.

The password field provided the first clue. Analysis showed that the data were forwarded immediately to another server. From there, the investigators identified the communication mechanism, including a Telegram chat ID, a bot token and the bot used to notify the attacker.

Figure 4. Response from the Telegram bot

The process was simple and efficient. A customer entered credentials on the cloned page. The Telegram bot notified the criminal, who could then continue the account takeover.

Once defenders understand that workflow, they have more options. Disrupting the notification channel can prevent the attacker from receiving newly captured data even if the phishing page remains online for a time.

Phishing Kits Leave Their Own Technical Fingerprints

Modern phishing infrastructure is often assembled from ready-made components. A campaign may use a cloned login page, an administration panel, a database, a Telegram notification bot, upload tools, concealed web shells and several server directories.

In one case, the attackers concealed a web shell inside an image. The upload function formally accepted only JPG, JPEG, PNG and GIF files. The malicious component was embedded in an apparently valid image and later activated to obtain access.

Understanding how such infrastructure works gives the security team reusable indicators. IP addresses, domains, hashes, file paths and recurring code patterns can all support further detection.

Threat intelligence becomes valuable when these findings move beyond the investigation. A domain can be blocked. A detection rule can be created. Customers can be warned. Related campaigns can be identified before they reach the same scale.

Early Detection Depends on Combining Weak Signals

The HTTP Referer header can provide one source of information when searching for phishing sites. Words or patterns associated with well-known services, marketplaces and payment journeys may indicate that a suspicious page is being used as part of a wider campaign.

Figure 5. HTTP Referer indicators used to generate an alert

A word in a header is not proof of fraud. Several weak indicators, however, may justify an alert and a closer look at the site.

This matters for banks and other organisations with large customer bases. Fraudulent messages sent directly to customers may never pass through corporate systems. Without external monitoring or customer reporting, the organisation has no reason to know that the campaign exists.

Effective phishing detection therefore draws on several sources: internal filtering, external infrastructure monitoring, customer reports and active threat intelligence. Each covers a different part of the attack surface.

Attackers’ Mistakes Create Opportunities

Cybercriminals are not always careful with their own security.

They leave directories open, protect administrative panels with weak passwords, store stolen information in accessible locations and test notification bots without removing the evidence. These mistakes can expose both the infrastructure and, occasionally, the people operating it.

One administration panel used admin as the username and 12345 as the password. It was an unsophisticated choice, but not an unusual one. Many phishing operations are assembled rapidly from templates, with more attention paid to collecting credentials than to securing the underlying tools.

Telegram channels and bots may reveal who created the channel, who belongs to it and who administers the operation. In some cases, attackers have tested bots by sending photographs, including selfies, leaving investigators with information that has nothing to do with the intended fraud.

No security strategy should depend on criminals being careless. Yet when they are, a team that knows how to preserve, analyse and use the evidence gains time.

The Bank’s Perimeter Is Not the Customer’s Perimeter

Inside a bank, email gateways and filtering systems stop a large share of malicious traffic. These controls are usually managed by internal security teams.

An ethical hacker looks at the problem from the customer’s side. The investigation begins with what the customer experiences: receiving the message, opening the link, reaching the cloned page, entering credentials and encountering an attempt to capture further authentication data.

These are different security environments. A bank may have excellent corporate email filtering and still know little about attacks sent directly to customers, suppliers or partners.

The financial and reputational consequences still fall on the organisation whose name is being misused.

Banks therefore need visibility beyond their internal networks. They need a route for customer reports, the ability to investigate fraudulent sites quickly and indicators that can identify related infrastructure before the campaign becomes widespread.

What Organisations Should Test

Can customers and partners report suspicious messages easily?

If an attack never enters the corporate environment, the organisation depends on external reports. Those reports need a clear route into the security process, followed by validation and escalation.

How quickly can the team move from a fake page to the infrastructure behind it?

The website is only the visible layer. Investigators need to understand where it is hosted, what it collects, where the data are sent and how the attacker is notified.

Does threat intelligence trigger an operational response?

Dark-web monitoring and lists of domains, IP addresses, hashes or exposed directories have little value on their own. The information needs to lead to a warning, a block, a detection rule or a referral to the team able to act.

Is too much responsibility placed on the customer?

A well-built phishing page may be almost indistinguishable from the legitimate service. Customer awareness remains important, but it cannot be the final control. Security needs to work even when someone clicks the link.

Can the organisation use an attacker’s mistake quickly and lawfully?

An exposed directory or poorly secured bot creates a window of opportunity, not a permanent advantage. The organisation needs the skills, authority and escalation route to turn that evidence into action before the attacker rebuilds elsewhere.

Phishing attacks exploit trust, but they are also operational contests. Attackers collect information, test their infrastructure and adapt their campaign. Defenders need to do the same faster.

The advantage rarely comes from one tool. It comes from recognising a mistake in the attacker’s infrastructure and turning it into a warning, a detection rule or a disrupted campaign before the next customer is reached.