Ready-to-go phishing kits make it quick and easy for novice criminals to deploy new phishing sites and receive stolen credentials.
Phishing kits are typically ZIP files containing web pages, PHP scripts and images that convincingly impersonate genuine websites. Coupled with simple configuration files that make it easy to choose where stolen credentials are sent, criminals can upload and install a phishing site with relatively little technical knowledge. In most cases, the credentials stolen by these phishing sites are automatically emailed directly to the criminals who deploy the kits.
However, the criminals who originally authored these kits often include extra code that surreptitiously emails a copy of the stolen credentials to them. This allows a kit’s author to receive huge amounts of stolen credentials while other criminals are effectively deploying the kit on their behalf. This undesirable functionality is often hidden by obfuscating the kit’s source code, or by cleverly disguising the nefarious code to look benign. Some kits even hide code inside image files, where it is very unlikely to be noticed by any of the criminals who deploy the kits.
Netcraft has analysed thousands of phishing kits in detail and identified the most common techniques phishing kit authors use to ensure that they also receive a copy of any stolen credentials via email.
The Motivation Behind Creating Deceptive Phishing Kits
When a phishing kit is deployed, the resultant phishing site will convincingly impersonate a financial institution or other target in order to coax victims into submitting passwords, credit card numbers, addresses, or other credentials. These details will occasionally be logged on the server, but more often than not, are emailed directly to the criminals who install these phishing kits.
Directory structure of an Amazon phishing kit contained in a ZIP file archive.
Phishing kits are very easy to install, and so they are widely used by “script kiddies” and other criminals with relatively little technical knowledge. The author of the phishing kit will rely on these people to orchestrate an entire phishing attack on their behalf. The grunt work includes deploying the kit onto various web servers and sending thousands of specially crafted phishing emails to trick victims into visiting the new phishing sites and surrendering their credentials.
By making a kit easier to use, its author can benefit from a greater number of deployments, which in turn will lead to a larger haul of stolen credentials for the author. A typical kit is supplied with instructions and a configuration file, which is where the criminals who deploy the kit are told to enter their own email addresses in order to receive any stolen credentials.
When a criminal deploys a phishing kit, it is likely that they will test it by submitting some fake credentials to check that the credentials are correctly received via email. If this works as expected, then the criminal will start the process of spamming thousands of potential victims with phishing emails, most likely not realising that the stolen credentials will also end up being sent to someone else.
Hiding inside image files
The following directory of images resides in a phishing kit that steals online banking credentials. Most of these files are logos and background images that will be displayed by the phishing site, but the button.gif file instead contains PHP source code. The name of this file and its placement within the images directory is a clear attempt to hide the code and its functionality.
The button.gif file in the images directory.
When a victim enters their password into the deployed phishing site, it is submitted to a script named next2.php, which emails the stolen credentials to the criminal who deployed the kit as intended. Currently it is configured to send the credentials to chrishennedy12@gmail.com and epena2016@gmail.com.
The script that sends the stolen credentials includes the button.gif script.
However, the highlighted line of code above includes the button.gif file, causing the following “hidden” script to be executed:
Obfuscated PHP source code inside button.gif.
To further hide the purpose of this code, it has been obfuscated by the kit’s author. The payload is hidden within a Base64-encoded string, making it unintelligible to most. By reversing this string, applying a ROT13 substitution cipher, and then decompressing the decoded contents, it can be seen that the script generates the following PHP code:
The de-obfuscated PHP code.
This code is then executed by passing it to the PHP eval function, resulting in a copy of the stolen credentials being secretly sent to three additional email addresses: equallicQ2@gmail.com, tesnatback@gmail.com and tesnatback@hotmail.com.
These hidden email addresses were likely added by the kit’s author, or unwittingly copied from a previous kit created by another criminal. The original author of the hidden functionality stands to benefit by receiving a copy of the credentials stolen by all deployments of the kit, which highlights the necessity to identify these hidden email addresses.
For example, if a thousand individual criminals were to deploy this kit 10 times each, and each phishing site successfully attracted only 100 victims, each criminal would receive a thousand sets of stolen credentials. The kit’s author, on the other hand, would receive a million sets of stolen credentials with minimal effort, and would likely continue to receive many more.
Hiding within access control scripts
Most phishing kits include one or more scripts that prevent phishing content being displayed to certain IP addresses, hostnames and browser types. The motivation for this is to prevent the deployed phishing sites being indexed by search engines and to make it harder for anti-phishing organisations to detect the attack.
An effective suite of access control scripts is therefore likely to be copied by other criminals and used in new kits, and so these scripts are often a good place for kit authors to add hidden functionality like backdoors and additional emails addresses that would allow them to receive even more stolen credentials directly from other criminals’ kits.
For example, the following suite of access control scripts was found in a kit that targets customers of a postal service company:
Anti-bot access control scripts in a phishing kit.
The BOT7.php access control script includes the following obfuscated code near the end of the file:
Obfuscated code near the end of the file.
This has the effect of appending sllershopxz@gmail.com to the list of email addresses that the kit will send it stolen credentials to, allowing the kit’s author to receive credentials stolen by all deployments of the kit.
Although the type of obfuscation used in this example is fairly simplistic, it is still likely to deter the majority of criminals who deploy the kits from noticing, removing, or otherwise tampering with the code, thus preserving the hidden undesirable functionality. Many hidden features analysed by Netcraft feature much more extensive levels of obfuscation that require considerable expertise to decipher, further increasing their chances of remaining in future deployments and variations of the same phishing kit.
Hiding in plain sight
This AES.php script is contained within a very large phishing kit that initially impersonates HMRC and then impersonates one of several UK banks, depending on which one the victim is a customer of. These banks include HSBC, Tesco Bank, TSB, Metro Bank, Bank of Scotland, NatWest, Lloyds Bank, Halifax, Santander, Barclays and Cooperative Bank.
The AES.php script in the phishing kit.
The kit allows stolen credentials to be encrypted before being logged on the phishing site, thus ensuring they can only be read by the criminal behind the attack. The presence of the AES.php script is therefore no surprise, and indeed at first glance it does appear to provide a set of AES (Advanced Encryption Standard) properties and functions:
A PHP implementation of AES.
However, the get58V function within the AES class includes two errant lines of code (highlighted below) that send a copy of the stolen credentials to hmrcsup@protonmail.com. This happens regardless of whether the kit’s encryption feature is actually enabled.
PHP code that emails the stolen credentials to another address.
Despite hiding in plain sight, this additional email address is still unlikely to be noticed by most of the criminals who deploy the kit. AES implementations are hard to follow without expert familiarity, and as most deployments of these kits do not enable the encryption feature, even a suspicious criminal may not think to look inside this script at all. The lack of obfuscation could backfire, though, as if another criminal does discover this code, it will be trivial to change the email address that all future stolen credentials will be sent to.
Mitigations
The presence of obfuscated email addresses in phishing kits highlights the importance of using countermeasures and phishing kit analysis services. It is imperative to identify and shut down all email accounts that a phishing site sends its stolen credentials to as this instantly limits the impact of an ongoing phishing attack, especially when most kits still use email as the sole means of transmitting stolen credentials.
However, as we have shown above, some kits use devious techniques to send stolen credentials to other email addresses which are operated by the authors of the kits. These “hidden” addresses are typically much harder to find and can only practically be discovered with the thorough analysis provided by Netcraft.
Failing to identify and take down these hidden email accounts would be a critical mistake, as they would otherwise allow a kit’s author to receive a significant amount of stolen credentials from all existing and future deployments of the same kit.
As phishing kit authors often use existing kits as a basis for creating new ones, a cleverly hidden email address is likely to end up being propagated to new kits made by other authors, making it even more crucial to ensure that these hidden addresses are identified and taken down.
Thwarting a criminal’s ability to receive stolen credentials can have a profound effect. One bank receiving phishing kit analysis and countermeasures from Netcraft has seen a remarkable reduction in the number of distinct phishing kits targeting its customers over the past two years, likely a testament to the effectiveness of this approach, with criminals instead preferring to find easier and less frustrating targets.
This is not the only benefit provided by the service – it is also a useful way of identifying new attack trends and other powerful mitigation opportunities in the kits that target your organisation.
