Microsoft SafeLinks Redirect: TattleToken Script

Attackers are using 'smart' redirect servers to hide malicious websites from post-delivery protections like Microsoft SafeLinks and Chrome browser filters. 

Summary:

Attackers are using client-side scripts to determine the end user's IP address and altering the URL in order to hide a malicious server from email service providers and security organizations.

If you click on a link from a Microsoft, Google, Symantec or Avast network, for example, the server will return a benign webpage. This includes clicks from SafeLink scanners, web browser filters, sandbox emulators, security labs, threat-feeds and other automated systems that scan websites for phishing or malware content.

If you click from your office or your home, the server will deliver a personalized phishing page.

This effectively bypasses most post-delivery protections like O365 SafeLinks inbox retraction. 

Background

While attackers continue to create new ways to reach your inbox, the innovation in the phishing arms race is happening post-delivery. In the last couple of years, email providers and security providers created tools to protect users from malicious links that bypass pre-delivery filters and reach the inbox:

• Time-of-click protections like Microsoft SafeLinks that will scan a website when a user clicks on an email link,
• Post-delivery retraction of emails that contain a malicious URL,
• Web-browser filters that will automatically block a URL if it is known to be malicious.

One method of protecting their malicious servers from detection is with a Gatekeeper Redirect. Instead of putting the malicious URL in the email, hackers link to a redirect server that acts as a gateway, sending queries from a security company to a benign site. Queries from the intended victims are directed to the phishing server.

The TattleToken Script

The TattleToken script is one of many types of SiteCloaking methods. It is interesting to us because the work is done on the client, so that we can analyze the code and see it in action.

• The user receives a URL which includes a key and an encoded version of their email address:

• If the ‘key’ field (key1234) is missing or incorrect, the server redirects the user to google.com
• If the ‘key’ field is included, the server replies with the TattleToken script:

• This very simple script makes a query to https://ipapi.co/org. You can try it yourself. This publicly available service will tell you your Internet Service provider. Go ahead, click. 
• The script includes the names of all the major security vendors, email providers and other firms that they want to block. A match will change the URL token to tell the server that the query is coming from one of the security vendors (“YuT4XAKJ”).
• Otherwise, the script will send an ‘all clear’ token (“iKaLo89a”) and include the victim’s email address so that the server can present the victim with a login page already filled out.

From the point of view of the security firms, the link in the email is just a simple redirect to Google’s web server. When the victim clicks on the same link, she is redirected to the malicious web server.

Targeted Attacks

While the TattleToken script effectively filters out security vendors for general campaigns, the same script has been used for targeted attacks. Essentially, the attacker writes the script to exclude every IP except for the domain of the intended victim. We deem these highly critical because they indicate that other highly targeted attack methods may also be in use.

The GateKeeper Redirect

This is just one example of the GateKeeper Redirect method of hiding malicious servers from email and security providers. More often, the processing and redirect filtering is done on the server rather than within the client-side browser. These, of course, are much more difficult to detect.

Most security vendors are still vulnerable to more widespread GateKeeper Redirect methods. They all use similar logic to hide malicious sites from post-delivery protections. While the TattleToken script uses the client IP address to determine the source of a click, server side methods might use other metrics like web-agent tokens or even popular client cookies from Facebook or Linkedin.

As the phishing battlefield moves from pre-inbox filters to post-delivery protections, we are seeing a new surge in techniques that successfully bypass most email security tools.