Adrian Hada
ATI Security Researcher

An Overview of Phishing Attempts in the Wild

October 5, 2018 by Adrian Hada

Phishing is one of the easiest, and most efficient, tools to use for attackers in the wild. Even with excellent technical security practices in place, it can be extremely hard to combat the results of social engineering. As a result, identifying phishing pages in the wild is extremely important to us, here at the Application and Threat Intelligence (ATI) Research Center.

One might wonder why it’s so hard to block phishing attacks. From my experience, there are three primary challenges of securing against web-based phishing attacks:

  1. Attackers go through great lengths to mislead users
  2. Attackers resort to simple but clever schemes to bypass detection
  3. Attackers deploy their “phishing kits” at scale to increase their odds of improving the phishing page’s uptime and to have a better chance of someone being baited

In this article, I’ll walk you through some of the techniques that are used to increase the chances of successful phishing attack, as well as some examples of failures on the malicious actor’s part.

Misleading Tactics

Phishing relies on a clever combination of visual cues that users will relate to, gaining their confidence that the page they’re trying to access is actually a legitimate place to type their credentials. The simplest way to do this, of course, is to clone an original web page. Here’s an example of a cloned GoDaddy webmail login page:



The two pages are identical, except for some minor visual differences and the copyright note at the end – the clone appears to have been created in 2017, explaining the minimal differences in appearance. 

In this case, the change in the template was hard to spot. Other cases are a bit more blatant. Here are some examples of Google credential phishing attempts:


The first two are almost identical – being given just the images themselves, it’s hard to realize which is the original page and which is the phishing page (I’ll help you with that one – the first is the correct login page at the time of writing). The third is clearly a clone of an older page; at some point in the past, Google has modified the look of the login page as well as requiring the email and password to be submitted in two different steps in the login process. However, it’s possible that a user might be fooled by this older template after having seen and trusted it for a good amount of time. 

Sometimes, however, plain old cloning is not the best way to go. For one thing, modifying the template makes it more difficult for detection devices to identify the phishing attempt. For another, you can easily claim to the user that they can login using other known credential providers and catch more than one fish. Don’t have a Dropbox account? Login using AOL, Yahoo, or whatever you desire instead:


Another neat trick is adding the target’s e-mail address to the login form – it seems safe if it’s destined for you, right?

And if you’re feeling safe because you live in Hungary or Thailand, you can be sure there’s someone out there hoping to phish you too.



The point of these examples is: anything can be a phishing target, no matter how large or small. And even though the malicious actors might sometimes commit mistakes in their phishing attempts, the number of large and common visual cues can sometimes mislead people, especially if the phishing attempt comes with a panic-inducing message such as foreclosures, breaches, or account blockages. 

Bypassing Detection

Technically, if bad actors would resort to simply copy-pasting the original HTML of the website, it would be easy for a security device to inspect the originals periodically and check whether the phishing candidate is coming from a legitimate or illegitimate domain. In practice, this is not as easy as it sounds, especially since the actors are aware of this themselves and take steps to reduce the number of indicators that can be used to identify phishing attempts.

Returning to the two very similar Google login pages before, here’s a quick view of the HTML source code of the original and phishing pages:



Google’s page is a whole bunch of Javascript code, while the threat actor relied mostly on plain-old HTML. This is a result of the fact that HTML allows you to obtain the same visual result by different means. 

You might also think that identifying keywords might help with identifying phishing pages. For example, just search for “Sign Up”, “Password”, “PayPal” and other keywords and you might identify some phishing attempts. Unfortunately, the bad guys thought about this as well. Here are some examples of them evading such attempts:


In this case, the attacker relied on the special character “Rho” of the Greek alphabet which is visually similar to the letter “P”.

HTML also allows you to specify such substitutions using the equivalent ASCII codes instead of the character itself. Here’s an example:

Using Python, decoding is simple:

The visual output of the HTML code confirms that we’re dealing with a Chase Online phishing attempt:


One more advanced technique relies on Javascript manipulation of the web page. The attacker generates the phishing template, encrypts it using AES via a Javascript implementation of it such as this one, and decrypts in the user’s browser when the page is accessed. Example code and rendered phishing page below.



Deploying at Scale

A successful phishing attempt can be extremely destructive to an individual or organization. However, most of these attacks fail. There are several factors that lead to this, including improvements in security device detection, faster responses from hosting providers when pages get detected, sharing of known phishing pages between security entities, as well as improved user awareness of the threat.

All of these lead to a requirement on the attacker’s part that they are able to deploy their infrastructure at large, move faster than defenders are able to respond, and target a large audience to find more people that are likely to respond to the attempts.

As a result, attackers use “phish kits,” preparing web page templates for one or multiple targets, adding them to a zip file and deploying said zip file on a large number of websites – either hosts that have been registered by the attacker (using fake credentials and stolen credit cards) or hacked. 
Here’s an example phish kit:


The zip file contains HTML, CSS code, and an image of a Microsoft logo. The .php file is used to process the submitted data – in this case, sending an e-mail with the visitor’s IP address and submitted username and password. After stealing the credentials, the authors are kind enough to redirect the user to the legitimate Office login page, so they can finally get their work done. Everything names Office as the target except for the line containing “Citi LOGIN” – it’s likely that some of this code was reused after attempting to steal Citibank user data.

This is not a random happening. In fact, phishing templates get used and adapted for new targets and different types of data very often. The attacker might choose to phish credentials, banking details, or other types of useful personal information. For example, this template is often reused for different phishing targets:


With a couple of modifications to the styling of the page and changing the loaded images, we can obtain these three different phishing pages:




The first page asks for credit card data, while the other ones are kind enough to limit themselves to a password (the e-mail address was pre-populated in the template, I removed it for anonymity). This way, the attacker can easily deploy phishing pages at scale for many targets, different languages, modified target data, and other purposes.

Phishing can be difficult to spot and even more difficult to classify. In this respect, we hope the research we do on these websites and the information we disseminate will aid people in being safer on the Internet. Phishing pages we identify and track in the wild are constantly sent to our ThreatARMOR product, so customers are protected against these attacks. Stay safe!

Leverage Subscription Service to Stay Ahead of Attacks

The Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.