Share:

By Noah Mizell and Kyle Duncan, Cofense Phishing Defense Center

The Phishing Defense Center (PDC) has discovered two distinct phishing campaigns found in environments protected by Proofpoint that spoof Twitter by using registered fraudulent domains.

Threat actors utilize numerous attacks throughout their careers; others stick with tried-and-true attacks proven to be effective. The latter is the case in the following scenarios with these attacks coming from the same campaign based on similar tactics: registered fraudulent domains, specifically tailored sender emails, and nearly identical phishing emails and pages.

Figures 1-2: First Iteration of Attack

The subject of the phishing email is “Security alert: new or unusual login” followed by the sender email “verify[@]tlwtttierz[.]com”.  Although it is obviously not Twitter.com, it is similar to the actual name, that users may overlook due to the urgent tone.  However, users must be careful when reacting in haste, as threat actors seek to turn quick thinking against targets to steal their credentials.

The body of the email looks like a legitimate Twitter notification. Similar font type, layout, the familiar Twitter logo showing – nothing appears to be amiss. Reading the contents of the message though, users may be surprised to see there has been a new login from a new device from Spain! Supposing the user is not connected to this location, this is likely to be cause for concern. But worry not, “Twitter” has sent a handy link to secure the account in question.

Hovering over the link “Secure my account”, it shows the redirect is:

twltt%C4%99r[.]com

However once clicked, users are sent to a URL that looks like “Twitter.com”:

twlttęr[.]com

For this attack, the threat actor uses punycode to make the final URL look like “Twitter.com”. The use of punycode has been noted as an extremely easy way to make phishing URLs look very similar to the site they are impersonating. Punycode essentially takes words that cannot be written in ASCII and puts them into an ASCII encoding that browsers will understand.

For example, the URL to which the attack directs does not actually include a letter ‘e’ ASCII would understand; it uses the hexadecimal encoding ‘C4 99’ for a character that can be seen in the first URL. When the browser gets this encoding, twltt%C4%99r, it renders the string, %C4%99, to the Polish letter ę, which just so happens to look very similar to the ‘e’ we’re used to seeing in the legitimate Twitter.com URL.

Figure 3-4: Second Iteration of Attack 

Although this second attack may appear to be the same one from Figures 1-2, it is an improvement – the threat actor made minor tweaks to enhance its believability.

The subject of the email has changed: “New login from Safari on iPhone”. Like the previous attack’s subject, this is also meant to evoke a sense of urgency. This time, however, the sender email is not the obviously wrong “verify[@]tlwtttierz[.]com” but rather a more subtle “verify[@]mobiles-twitter[.]com”.

Although this email looks like an exact copy of the last attack, the threat actor added a small yet impactful detail: at the bottom they specifically reference the recipient: “We sent this email to _____”. Most users have been told to look out for generic “Dear sir/ma’am” terms in emails. If the email is not specifically addressed to the recipient, it is likely a mass mailing, perhaps with malicious intent. For most users, personalization adds legitimacy.

Like in the last attack, the threat actor included disclaimer under this hyperlink to “help” users know this is a legitimate email from Twitter. Both emails mention the display of a padlock to mean a secure and legitimate site. This padlock only shows that the website is using an active SSL certificate to signify encrypted communications between the user and the web server.  However, contrary to widespread belief, a padlock does not equal safe. The attacker is simply trying to erase any doubts about the site.

The final change of this second attack can be seen when hovering over the “Confirm my identity” hyperlink and finding a new fraudulent domain:

mobiles-twitter[.]comThis domain appears to be more legitimate than the one from the first attack, as it contains the word “twitter”. Considering mobile[.]twitter[.]com leads to the legitimate mobile version of Twitter, this “mobiles-twitter[.]com” was more than likely supposed to be a dupe.

Perhaps this attack may have intended to typosquatt to lure victims the attacker never initially targeted. Typosquatting, or URL hijacking, relies on users making small mistakes when typing a URL, whether adding a period where there was a dash or misspelling the domain. The attacker has registered that mistakenly typed out URL, so should anyone accidentally visit it they will be subject to whatever is on that page.

Figure 5: Phishing Page

As seen in Figure 5 above, users are presented with a login page for either attack, however this one is specifically for the phish located at twlttęr[.]com. This page is made to look extremely close to the current Twitter login page that can be seen on a desktop browser. The obvious difference between this phishing attack and the legitimate Twitter login page would be the URL, with its unusual letter ‘ę’, and the atypical tab icon.

This is just the first iteration of the threat actor’s attack. The second attack has an even more dismissible body email and a URL that looks closer to a legitimate URL. Regardless, it is no secret that users should pay close attention to the URLs in their address bar.

 

Network IOCs  IPs  
hXXps://mobiles-twitter[.]com/login/ 70[.]37[.]100[.]82
hXXps://twltt%C4%99r[.]com 70[.]37[.]100[.]82
hXXps://xn--twlttr-04a[.]com/login/ 70[.]37[.]100[.]82
hXXps://t[.]co/U6DLQ2B1xC

 

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.