FireEye has identified a campaign involving phishing websites that appear as legitimate Amazon sites. Amazon is the largest online retailer and threat actors frequently target its customers. In this attack, a person browsing the internet would be directed to authentic looking – yet fake – Amazon webpages that request a variety of information, including Amazon credentials, home address and payment card data. Any information entered into the phishing websites could be sent to the attackers and potentially used to make fraudulent charges and commit other crimes.
FireEye detected this phishing campaign through our email MPS platform and has seen attacks primarily targeting Amazon customers in the U.S., Canada and Europe. FireEye has made Amazon.com aware of this phishing campaign. In addition to aggressively investigating all suspicious email reports, Amazon.com provides resources for customers to identify whether an email is from Amazon.com and to protect their systems.
While there have been numerous reports on Amazon phishing attacks in the past, this campaign is particularly interesting for security analysts because of the evasion techniques being used by the attackers. Though various instances of this phishing practice have been previously used, we’ve been following this particular campaign variant since June 21, 2016. Some of the evasion techniques used in this campaign include:
After clicking the initial URL, the user is redirected to the phishing template page hosted on another compromised site. The campaign is browser-aware in terms of the URL it displays in the browser. Hexadecimal encoded domains are displayed when Firefox or Safari are used while clear text is displayed in Chrome. An example rendering is shown in Figure 1.
Figure 1. Initial Phishing Page
To the user, the page appears to be a legitimate Amazon login page. Behind the scenes, however, numerical HTML encoding of Unicode characters are prevalent throughout the page serving up the fake Amazon login page, as shown in Figure 2. This tactic helps to evade text-based detections.
Figure 2. Numerical HTML encoding of Unicode Characters in the Amazon phishing page.
The malicious actor behind this phishing campaign regularly updated connect.php on the initial compromised host. The purpose of the initial host is to redirect users to infected machines hosting phishing sites where the phishing template page has been uploaded. As these endpoint phishing sites get taken down, a new one is established and the redirection page is modified to point to the new phishing page location.
Figure 3 shows an example of a complete redirection chain.
Figure 3. Redirection Chain example
After the initial redirection to the second URL in the chain, the first thing the server does is include an anti-detection module. This anti-detection module blocks certain IPs, including search engines such as Google, anti-phishing tools such as Netcraft, and other network service providers. This makes the website not detectable by bots by returning a 404 Not Found page instead of continuing redirection to the phishing template. An example of the extracted IP based anti-detection code is shown in Figure 4.
Figure 4. IP based anti-detection code
The next action the server takes if their IP is not banned is to record a log of the victims who visit the page. Code extracted shows that the logging includes the visitor’s IP, user-agent, operating system, browser, hostname and referer information, as shown in Figure 5.
Figure 5. Visitor tracking code
Figure 6 shows the debug log file left by the template writer.
Figure 6. Debug log file
After logging the user information, code is executed to create a random md5 hash path name for the phishing page that will ultimately be served to the end user. After all resources are copied to the random path, the server redirects the visitor to this path (redirections 3 through 5 in Figure 3), thus rendering the actual phishing page in the user’s browser. The code responsible for generating the random path is shown in Figure 7.
Figure 7. Path randomization code
At this point, the initial phishing template page shown in Figure 1 is rendered in the user’s browser. After entering their initial login credentials, the user is taken through a series of two more pages shown in Figure 8 and Figure 9. This is to harvest address and billing information.
Figure 8. Fake Address Verification Page
Figure 9. Fake Billing Information Page
After the victim has entered all the requested information, the server sends an email containing the information to the attacker’s email address and redirects the user to the real Amazon webpage.
The code shown in Figure 10 is the code that builds the email message sent to the phisher.
Figure 10. Email building code
The victim’s information is contained in the $message variable that is built from the user’s responses to the pages shown in Figure 8 and Figure 9. Figure 11 shows the code that builds the message contents, which contains the harvested user’s information.
Figure 11. Message building code
After the harvested credentials are emailed to the attackers, the user is sent a final redirection to the legitimate Amazon page. The code behind this redirection is shown in Figure 12.
Figure 12. Final redirection
Detecting these types of threats can be tricky, particularly when the attacker is leveraging some interesting evasion techniques. Oftentimes users are redirected to phishing pages after clicking on a malicious link. FireEye recommends that users exercise caution when clicking on links from untrusted parties, avoid opening emails from unknown senders, and be wary of emails from anyone requesting personally identifiable information. Additionally, and most importantly, users should only log into Amazon by visiting the website directly.