Inside a phishing panel (2024)

Introduction

Dutch and Belgium citizens are receiving phishing attacks every day. But how does that exactly work?

Phishers are approaching citizens through mail, text messages, WhatsApp or auction platforms. They are trying to lure the victim to a phishing site to fill in their credentials. Those credentials then are used to gain access to the bank account of the victim.

While investigating the phishing frameworks that are used, we see continuous innovation in knowledge and tools the phishers use. They improve their attack scenario’s all the time, which is for a large part why these scams are so successful.

Analyzing phishing sites is fun!

At Zolder we are actively monitoring for phishing sites targeting Dutch and Belgium users. A very valuable source to do so are the certificate transparency logs. These were introduced to improve reliability of the decentralized nature of the certificate ecosystem. The goal of the initiative is to make the ecosystem more transparent by giving everyone around the globe the ability to monitor and/or audit certificates being issued by the different authorities. One of the reasons is the hack performed at DigiNotar back in 2011.

Our monitoring system finds potential phishing URLs in the transparency logs. We get many phishing sites that are being used to perform attacks against Dutch and Belgium citizens. Usually the main goal of those attacks is to obtain access to the bank accounts of the victims. We have seen almost every bank in The Netherlands and Belgium being imitated for these kind of scams..

It’s fun to investigate the phishing sites that we see being setup. After a while, one will start to recognize the specific frameworks being used, the different techniques or even discover who has been (successfully) targeted by the attacks. So, you can probably imagine: that’s just really fun to do 😀.

New framework

Recently we stumbled upon a new phishing framework. The framework is called Universal Admin, better known as “uAdmin”. After some time, we were able to get our hands on the source code of the uAdmin framework. This was great, as it allows us to see the internal working of such a phishing scam. By analyzing the source code we determined some interesting facts.

Separated phishing page and admin panel

uAdmin consists of two main components. The first part is a phishing page, also called “FAKES”. Those fakes are the phishing pages that the victim will see. For example: a fake ING or ABN login page. The fake pages look remarkably similar to the legitimate ones and will be hard to distinguish from real. All the information that a victim fills in into the fake is sent to the attacker.

The second part is the uAdmin panel. This is only accessible to the attacker, and allows him to see the status of the attack. Furthermore the panel allows the attacker to perform specific actions targeted at the current visitor on the phishing site.

The admin panel can be hosted on a system different from the phishing site. This has the advantage that usually at one point the fake is taken down by the hosting provider. When separated, the admin panel in that case will just stay online. The attacker just installs the fakes on a new system and carry on. The following graphic shows when separated systems are used:

Extendable

uAdmin is an extendable framework. The code we obtained included fake sites for these banks by default: ING, ABN, SNS and Regiobank. It is possible to extend the framework easily with other phishing pages. Someone with PHP coding experience is even able to write his own custom phishing pages. So far, we have seen phishing pages for the following companies using the uAdmin framework:

• bunq
• Triodos
• ASN
• Rabobank
• KNAB
• PostNL
• Marktplaats
• MijnOverheid
• DigiD
• ING Betaalverzoek
• ING BE
• BEOBANK
• BNP
• Argenta
• AXA
• KBC
• Belfius
• Fortis
• FOD
• CSAM

We have also seen a few fakes imitating banks from Germany (Sparkasse and Commerzbank) and Spain (Caixa Es and Santadar).

Man in the middle

This uAdmin framework is built to perform man-in-the-middle attacks. This makes the framework very powerful. The attacker sits between the victim and his bank, and lures his prey through all steps that are required to take over the bank account.

For example: the victim fills in the username and password of his bank account. After that he will be prompted a waiting screen (something to educate users on: banks never show spinning waiting icons for a very long time). Meanwhile, the attacker logs in with the stolen credentials at the real bank. The bank now prompts the attacker for the second factor in the login process. Which the attacker copies, and serves to the victim on the phishing site. The attacker is going to wait for the victim to login through his second factor device and return the information through the phishing page. Once submitted, the attacker will use this information to get access to the real bank. The victim then is forwarded to the legitimate banking site and probably will think an unimportant glitch occurred. At the same time the criminal is in the bank account and will order a money mule to send the money to and will withdraw it from an ATM.

The required steps differ for each bank. That’s why for every bank specific fake pages are available with different functions. But the idea is the same: request information from the victim or let them take actions (e.g. approve something on the mobile). Also, the flexibility of this panel enables the creativity of the phishers. We have even seen a panel that allowed a phisher to push a malicious APK file (mobile app for Android devices) to a victim. That does not seem to be directly useful to phish bank accounts, but might be used for other criminal activities.

A typical attack

Let me make it more tangible with an example. This is a example flow of a typical phishing attack (might differ per bank).

• Message

  The phisher sends a message to the victim to lure him/her to a phishing site. The method and the scenarios used by the phishers are changing all the time. Victims are for example approached through text messages, e-mails, WhatsApp or auction sites.

• Fake Site

  the victim clicks on the link. A imitation of a legit website is shown. The URL might be an indication of a phishing attack. But usually the website and even the URL looks like the legit website.

• UADMIN

  The phisher gets a alarm in uAdmin that the victim has clicked the link. He is waiting the victim to fill in his/her first credentials.

• 1^ST FACTOR

  the victim fills in the first credentials. Depending on the bank, this might be a username / password combination or something generated by a external device (e-identifier, scanner, etc). After filling in a waiting screen is shown.

• Bank App

  the phisher gets the first credentials and opens the corresponding bank application on a phone. He fills in the information obtained from the victim, while the victim is still at the waiting screen. The app usually returns a response from the bank, such as a code.

• Command

  the phisher returns the response from the bank, back to the victim.

• 2^ND Factor

  the victim uses the response to perform second factor of the authentication process of his bank. He returns (if applicable) information of the second factor authentication back to the attacker by filling it into the phishing site. After filling in a waiting screen is shown again.

• Login

  the phisher uses the information to get access to the bank account of the victim.

• Forward

  the phisher redirects the user to another website, whenever he successfully obtained all required information. Usually the user is redirected to the legitimate website of his/her bank.

• Transfer

  the phisher transfers the money to a money mule.

• Cash Out

  the phisher / money mule cashes the money.

Conclusion

We have been analyzing attacks for over a year now. The uAdmin framework offers one of the most sophisticated panels that we have seen so far, mainly targeting Dutch and Belgian citizens.

The power behind this panel is its flexibility: the fact that the phisher can send the victim to whatever page or step he wants. This allows him to specifically point the victim to a phishing page, and request the information or push the action he needs at that moment to reach his goal.

For an attacker this flexibility is very useful. Let’s take the following example: he could first phish a victim to gain access to his bank account. But after that, the victim could be tricked a second time to fill in information, to make a payment above the limit of 5000 euro a day.

The flexibility also allows the attackers to quickly update their panel. If a bank changes its login procedure to prevent phishing attacks, the phishers just modify the fakes as well.

Another important feature is the way takedowns are circumvented. They have split up the actual phishing pages and the command and control panel. The phishing page might be taken down, but the admin panel remains untouched if no further investigation is performed.

Blogs

Zoldersessions