Skip to content

Attacked via SMS? Smishing examined

4. October 2022

Introduction

Almost everyone is familiar with the issue of spam: you receive e-mails telling you about unbeatable discounts, millions in winnings for your wallet or a blocked bank account. Often these are already filtered by spam filters before delivery or are unmasked by the numerous spelling mistakes and a strange sender address.

However, during our daily work at Pentest Factory, we were able to uncover a much more effective method to trick us into clicking on a malicious link: After a quick call to our mobile device, we receive the following SMS:

1 e1663244942666

Analysis

We open the link in a locked down virtual machine:

3 1

After a simple 301 redirect we reach the following page:

2 1

However, there is nothing out of the ordinary to be found at first glance. Even after analyzing the source code of the page, there are no special peculiarities to be seen.

However, we remember that the SMS was sent to a mobile device. Maybe it is possible to trigger a different behavior with a mobile user agent. We change our user agent to an ordinary Android Firefox browser. And look! We are now redirected to another page:

4 1

If we analyze the code of the page, we can see that it consists of 95% JavaScript code:

5 1

In our analysis of the code, we note that a series of checks are run to enumerate the properties of the browser and the underlying device:

6 1

These checks are located in separate functions (A1 to A91). These are iterated in a for loop and all parameters are queried. Afterwards all parameters returned by the check functions are converted to a JSON string.

This JSON string is then AES CBC encrypted using the JavaScript library “CryptoJS”:

7 1

The individual function calls and their names are obfuscated to make it difficult for a reader to understand the code:

An encoding function like 0x4ee32b takes an array position and a key as parameters. The section of JavaScript code we have called “encoded JavaScript” is a large array containing encoded function names (a so-called lookup table). If the function 0x4ee32b(index, key) is called, the value is read in the array at the corresponding index and this is decoded by means of the key parameter. This results in a final function name. Example:

8 1

This way CryptoJS[‘enc’][‘Utf8’][‘parse’] is called. A different way of writing CryptoJS.enc.Utf8.parse(string)

We stopped our debugger at the point where the array parameter is passed to the encryption routine:

9 1

You can see that, among other things, it reads out which user agent we use, CPU, operating system, device manufacturer, browser, as well as many other parameters, which functions are allowed or possible on our device.

Then, an encryption of these values takes place and, the page transmits this encrypted string to another page:

10 1

Once we arrive there, the server constructs a new redirect pointing to another host:

11 1

This next host receives an encrypted URL that is passed as a GET parameter, which is then redirected to in the final step.

In our case, we are redirected to the “TikTok” app in the Google PlayStore:12

In an article from Google it is described (https://blog.google/threat-analysis-group/protecting-android-users-from-0-day-attacks/), how similar behavior was used in 2021 to infect Android devices with a 0-day vulnerability. Here, a link was sent to the victims via e-mail. After clicking on the link, an exploit was executed in the browser to gain control over the underlying device. Similar to our example, the page finally redirects to a legitimate website.

Since we did not have a vulnerable Android device available, we can only guess if the site we analyzed also had a 0-day vulnerability or an attack planned against our device. However, we can assume that the detailed and obfuscated testing of all system parameters of our device is a preparatory step to analyze the compatibility of an attack with our device in advance.

Conclusion

Be vigilant against phishing attacks – not only emails but also SMS messages can reference malicious sites and prompt you to install malware (disguised as a useful app) on your device. As can also be seen in Google’s article, just one click (to find out what is behind the link) can be enough to launch an attack on the device and take it over completely.

In general, we recommend the following measures to protect against such attacks:

  • Keep all your devices up to date. Install security updates on a regular (automated) basis. This includes mobile devices. Use a mobile device management system to verify that all devices in your organization are compliant with patch levels and security policies.

  • Do not click on any links that cannot be trusted. This is especially true for messages from unknown senders. If in doubt, the message should first be forwarded to your security team for review.

Note: These recommendations are not an exhaustive list. If you are unsure whether you and your company are adequately protected against phishing, please contact us – we have many years of experience in protecting against phishing attacks and offer various services on a technical and personnel level. This includes:

  • Technical examination of your mail servers regarding the resilience and detection capability of phishing mails as well as malware, incl. a final report with hardening measures and insight into which attacks were successful.

  • Simulation of a real phishing attack to investigate how easily your employees become victims (anonymized evaluation also possible). Our attacks can be carried out by e-mail, telephone or physically (e.g. infected storage media).

  • Educate your employees in phishing seminars to improve awareness of attacks

  • Periodic repetition of simulated attacks to obtain progressive values of your anti-phishing measures and to examine the effectiveness of the measures