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 href="https://www.amazon.com/gp/help/customer/display.html?nodeId=201127830">suspicious
email reports, Amazon.com provides resources for customers to href="https://www.amazon.com/gp/help/customer/display.html?nodeId=15835501">identify
whether an email is from Amazon.com and to href="https://www.amazon.com/gp/help/customer/display.html?nodeId=201127790">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.