In the world of credential theft, phishing continues to be a popular method of attack. All that a cybercriminal needs to start are saved and modified login pages of a web site and some clever social engineering. Once the desired page is set up (often using throw-away or compromised domains) all that’s left is for the potential victim to browse the page. The primary delivery method for phishing links is email, but it is also possible to stumble upon phishing pages while web browsing.

Preventing phishing attacks is a challenge for any environment- some of the examples that follow may be helpful in hunting for indicators of phishing activity or educating users.

SUBDOMAIN SANDWHICH

A common tactic employed by Phishing pages is to sandwich familiar domains between one or more subdomains and another unaffiliated domain. This will then be followed by the top-level domain (TLD), which may look something like this:



hxxp://business.gmail.com.evilsite.biz/Gmail/

or

hxxp://company.docs.ymail.com.compromisedsite.org/webmail/

These are clearly not the real gmail.com or ymail.com, but users are regularly duped by this tactic because they neglect to check the address bar with enough scrutiny. They will instead use visuals as a method for determining if the page is authentic, meaning that a similar looking page can easily be successful. In these examples the actual phishing domain is in bold. The user may see the familiar domain in between but its only purpose there is to deceive.

Phishing pages may also embed the targeted domain after the phishing domain in the URL path to spoof the targeted web service domain.

Fig 1 – Most any login page can be faked, like this one. The crafted URL assists in tricking users.

Other observed behavior associated with phishing pages includes URLs like the one in Fig 2. Many follow a similar pattern of repeating the web service name in the URL.

Fig 2 – Dead giveaways include lack of HTTPS & an out of place web service name in the URL.

Phishing pages like these are very easy to spot. Browsers like Internet Explorer will usually give an indication that something is amiss, like greyed out text and/or a missing padlock.

Fig 3 – Example of greyed out text in address bar on a fake IRS page.

Fig 4 – Yet Another Phishing Page



When viewing a web page, you always want to ensure the connection is secured via HTTPS so that the communication is encrypted. In most cases phishing pages will not be HTTPS enabled.

In addition to the “HTTPS” protocol prefix, web browsers will show an indication (i.e. the padlock) when the connection is secured.

Some phishing pages may display the brand logo (favicon.icon) in the address bar as seen in Fig 1, which is enough for some users to ignore the missing security indicators.

This can also happen when the address bar truncates the full web address, such as with mobile devices or smaller browser windows. Despite the obvious ellipsis “…” indicating that there’s more to the URL, just seeing the familiar portion of the domain and web page graphics can be enough for a user to think a page is real.

Figure 5 – Example of truncated URL in address bar, actual phishing domain follows.

EVEN MORE PHAKE LOGINS



Fig 6 – Fake Google login pages. Can you spot the anomalies?

The aim of phishing pages is to steal credentials, but it is often done in a sloppy manner that can be spotted with a closer look at the page.

For example, logging into Gmail will not require you to enter your full phone number. This is an obvious attempt at tricking the user into giving up information that can potentially be used to hijack the account via password recovery.



Fig 7 – Phishing page that targets multiple web mail services on one page.

Some phishing pages go the extra mile and present the user with fake status pages that ultimately result in a phony error page alerting them that the request or transaction has failed. You are then redirected to the real web login page.



Fig 8 – After entering credentials, you are presented with a phony image to distract you.

DETECTION AND MITIGATION STRATEGIES

Current day email security solutions struggle to keep up with the influx of spam and phishing emails trying to reach users. Additional on-the-fly network detection can help give you better insight. By extracting indicators from phishing pages and associated network traffic we can build rules to alert us to the presence of identified phishing IOCs.

For example, a common pattern is a URL path crafted to mimic the respective web service. In Figure 9 we can see “/info/gdoc/” in the URL path of the HTTP request. Although this is bogus, it is useful as a possible indicator for other phishing pages because the URL path appears to stay static across different compromised domains.

This can be done for any pattern observed.



Fig 9 – Wireshark view of GET requests to phishing page, the POST is login info being sent.

You can also sometimes spot stolen credentials being sent over the network to a phishing page. More often than not the stolen credentials will be sent as plain text in an HTTP POST. Identifying this on the network is easy to do and can be used as a filter to look for other credentials being sent in the clear as seen here.



Figure 10 – Contents of the HTTP POST shows the clear text login info being sent.

Taking a closer look at a recent example of a phishing page targeting banks we can see the HTML source contains some potentially useful indicators for spotting similar pages.

The value for “name=” and “id=” looked unique so it seemed to be a good rule candidate.



Fig 11 - Looking at the fake login page’s HTML source reveals a couple odd strings.

To spot more we can create a quick Snort rule and see if more pages that use the string “chalbhai” show up on the network or in pcaps we collected.

Example Snort Rule:

(modify rule accordingly)

alert tcp any any -> any any (msg:"Possible Phishing Page Template or String"; file_data; content:" name=chalbhai id=chalbhai method=post>"; fast_pattern; sid:123456;)

Now whenever those strings used in that format show up in html, this rule should fire and potentially alert to the presence of another phishing page.

The same can be done for the indicators “/info/gdoc/” and the HTTP POST traffic. Together they can be used as a detection for this particular phishing page.

This is just one small example of extracting IOCs from a phishing page. Thousands of new phishing pages are created each day. Keeping an eye on which ones show up in your environment may be useful as a detection rule for your network or shared with the community.

Anomali makes the process of extracting IOCs from Phishing emails easy in the ThreatStream platform. Simply forward/upload suspect phishing emails and ThreatStream will rip out all the relevant indicators and integrate these with the threat intelligence platform.