Our team was recently alerted to a well-made phishing page targeting a large UK bank. During our investigation we found that this page was part of a larger “multi-part” phishing kit that did not function as common phishing kits do, instead using a central control panel. We were able to obtain the source code for all the parts of this kit and simulate an attack in our lab. Below we will outline what each part does, explaining each step in an attack and why this differs from common phishing kits. There will be a particular focus on the kit’s ability to capture two-factor authentication (2FA) tokens in real-time. It is also worth noting that this style of kit is modular: anyone can develop lures that work with the gateway and control panel. This can be particularly lucrative, as explained later in this article, because well-made lures can fetch substantial sums on the cybercriminal underground.
- A high-quality phishing page – the ‘lure’.
- An optional gateway to mask the location of the control panel.
- A control panel to which stolen credentials are sent.
The lure consists of two parts: an SMS message and a website to which the victim is sent. The SMS is nothing special, simply a short message with a link conveying a sense of urgency:
Example of a common phishing SMS
This attempt at preventing too much rational analysis of the message by the recipient is standard practice in phishing campaigns.
Once the victim follows the link, they are presented with a clone of the real banking page, complete with mobile detection and responsive design (see below). The page also drops a cookie to identify the victim if they were to visit the page again. This enables the attacker to keep their campaign organised as well as having functions in the phishing kit to block and redirect either victims they are not interested in or security professionals entering dummy details to track where the stolen information ends up.
The gateway is a small script that can be placed on another host to mask the real location of the control panel. The script takes the request from the phishing page and proxies it to the real control panel.
Using this, the threat actor can place their phishing pages – ‘the lures’ – on compromised hosts and the gateway on another compromised host. This allows the operator to keep the real admin panel on a machine under their control and the stolen credentials safe.
When an attacker uses the gateway, anyone looking at traffic from the lure page in an attempt to discover the control panel will only be able to see the gateway. If the gateway is taken down the attacker simply uploads it again elsewhere, repoints the lures to the new gateway and does not need to move the control panel and all its data.
The Control Panel
The control panel is where the attacker collects credentials and drives the attack. When a victim visits a lure, the page will beacon out to the control panel, triggering visual and audio notifications to alert the attacker that a victim is ready to be phished. The control panel can take input from multiple lures, allowing the attacker to manage their whole campaign from one place.
Using this phishing kit, therefore, an attacker can have lures for different banks and services all sending data back to one place in real-time. This is unlike common phishing kits which can only email stolen credentials to a configured email address: something that is extremely easy for security professionals to extract and take action on, or log to a local file to be collected later. If the lure is taken down before the logs are collected – whether by law enforcement or another malicious actor – the attacker would lose all of the stolen credentials.
The threat actor can also add users to split the workload between different gang members, as shown below:
Once the victim has arrived on the phishing page, a notification is triggered in the control panel – both a bell sound and a flashing red banner:
As you can see in the above image, the victim has entered their card number (a valid username for this bank) which has been passed on to the control panel. The victim is then presented with a loading notification while the kit waits for further instructions from the attacker:
This card number would then be used to start a session with the cybercriminal logging into the real online banking website. On that site, the attacker will be asked for certain characters from a password known to the victim – this changes with each login attempt so the victim would never enter their full password at any time. Consequently, the attacker needs to obtain this information from the victim.
Back-end panel to set which PIN and password characters to request
As this kit allows for real-time dynamic phishing, the attacker simply sets up a couple of options using a form on the control panel and pushes the correct page to the victim.
The dynamic part of this kit is used when the victim’s page is in a waiting state. The kit sends a query to the control panel every couple of seconds to poll for instructions. Once the attacker has filled out the variables – as in the example above where they require the third, fourth, and fifth numbers of the pin and the first, second, and fifth characters from the password – the lure page will pick this up on its next poll and display the correct page asking for the correct information. Once the victim has entered the information, they are placed back into a waiting state and the page polls for its next instruction.
Common phishing kits do not have this dynamic polling functionality. Therefore, unless they capture the entire PIN and password (which is not the normal log-in flow for this bank and would immediately raise suspicions) the attacker would be unable to log into the account.
Once the victim enters the required characters and clicks “Next”, the details are passed back to the control panel. The victim is again placed into a waiting state while the attacker continues to complete the process on the real website. On completion of this step, the attacker is ready to make a transaction.
There are a few different ways in which banks secure online transactions. These include an SMS or hardware generated token, both of which require the customer to enter a code into the website. As above, when capturing the password characters, the attacker only needs to provide a couple of options before pushing a fake 2FA page to the victim:
Token generator at back-end used by the threat actor
Fake 2FA page displayed to the victim
The details are once again passed back to the control panel for the attacker to use in their real session:
It is also worth noting that the attacker can request tokens, login information or other details as many times as they like. In order to add more legitimacy to repeat requests, the attacker can also trigger a notification claiming that there has been a suspicious transaction, which can then be chained with more token or password requests under the guise of cancelling a transaction.
Fake suspicious transaction notification
Fake one-time password (OTP) request
As shown above, these kits are far more advanced than the usual “passive” deploy and lure phishing kits that we are used to seeing in the wild, and they fetch a much higher price as a result. One dark web vendor monitored by Cyjax sells these kits for between $150 and $300, depending on the popularity of the bank and country.
Companies are starting to catch up with the rigorous demands of the current threat landscape and are applying multiple layers of two factor authentication to their pages. As a result, the traditional ‘deploy -> lure -> log’ phishing kits are becoming outdated as they are unable to capture time-limited tokens, such as SMS tokens, that may only be valid for around 10 to 15 minutes.
We predict that this newer and more dynamic style of phishing kit will grow in popularity across the board in the short- to medium-term. This is especially the case in the banking sector, however, as the extra time and effort required by the attacker to drive the flow of the phish is certainly worth the reward when targeting the right victims.