Catching a Rookie Mistake in a Facebook Phish

WatchGuard’s DNS-level protection and filtering service, DNSWatch, receives and processes numerous phishes every day. Many of these phishing attempts are monotonous and lack any unique qualities. However, periodically, the DNSWatch Tailored Analysis team triages a phishing attempt that stands out more than others. This short post will show a real-world phish that DNSWatch caught and how analysts were able to garner further information using trivial open-source tools because of a unique mistake by the attacker.

The Phish

URL: s3[.]us-west-1[.]wasabisys[.]com/tranqueavisp/indexs[.]html

When navigating to the site, there are immediate red flags. First, and the most obvious, the website shows a Facebook login page, but the URL is not from a Facebook domain. Second, the login page is displaying a warning banner in red-colored font that states: “Facebook needs to verify your account information to allow access to this video”. From that information, one can assume that this phish either derived from a Facebook video (or an impersonation of a Facebook video) or that the attacker intentionally placed the warning banner there to coerce victims into entering their credentials - a common tactic used in phishing campaigns to make a phish seem more genuine. Finally, at the time of this writing, the Facebook login page has been updated and no longer resembles what this phishing attempt is impersonating. You can view the current Facebook login page below.

Source Code Inspection

Using just the information above one can conclude that this is likely, if not certainly, a phishing attempt, but it never hurts to be curious. Upon inspecting the source code of the website and navigating to the authentication form there exists an obvious anomaly. When submitting credentials and clicking Continue, the form action submits a POST request to an external website – https://lsdd[.]host/mango.php. At this point you can be absolutely certain, if you weren’t already, that this is a phish. However, it doesn’t hurt to discover what role this website has in this phishing campaign by using a few open-source tools.

DNS Information

A DNS lookup shows that this domain is using Cloudflare as a proxy. However, the TXT record shows that the owner of this domain has an SPF record set using an unknown IP address – 94[.]242[.]61[.]15.

IP Address Lookup

Using an open-source tool such as Pulsedive shows that this IP address appears to be located in Moscow, Russia. It is also worth noting that this IP address has ports open for HTTP(S), FTP(S), IMAP(S), SMTP(S), and DNS. Facebook obviously doesn’t send authentication credentials to Moscow and it also wouldn’t have those ports open to the Internet. This attacker made the mistake of leaving their (possible) IP address in their SPF record revealing not only that this is a phish, but the possible fact that this IP address could that of the attacker themselves.

Conclusion

Based on the information gathered from analyzing the original website DNSWatch concluded the following:

• The initial phishing website impersonated Facebook and used a warning banner to coerce victims into entering credentials
• By looking at the source code it shows that submitting credentials attempts a POST request to https://lsdd[.]host/mango.php
• Doing a DNS lookup on lsdd[.]host shows that the attacker defined an SPF record of their probable real IP address
• Doing a lookup of this IP address shows that it originates from Moscow, RU (allegedly)