The goal of this blog post is to provide an approach to analyzing a text-based phish link. I will primarily focus on the initial steps to properly view the phish site from a non-mobile browser, provide OPSEC setup and browsing analysis recommendations, and conclude with defense measures to protect against such attacks.
While working a ransomware Incident Response engagement, a client received what seemed to be an unrelated Cash App-based text phish message (SMS phish or also known as Smishing) attack. A text message-based attack has all of the standard phish characteristics as an email message phish, but it arrives as a text message and usually takes a victim by surprise since the tactic is not as widely used.
The intent of this particular SMS phish analysis was not to derive attacker attribution (due to investigation time limitations) but to assist in determining the intent of the text message and, if possible, identify if there was any correlation to the current incident being investigated.
Research has shown an uptick in Cash App-based attacks, so although the phish attempt did not appear to be related to the incident at hand, the fact that an IT Administrator was specifically targeted was highly suspicious.
SMS Phish Information
While researching the email address used to send the phish text, I identified that it had no other social media profiles associated with it and appeared to have been recently created since there was no affiliated “first seen” date. These are notable indicators.
The site I used for this check was:
The SMS phish text tried to entice the potential victim to redeem a $750 cash reward. The malicious URL contained a shortened Twitter link from the attacker, based on the URL beginning with t.co. This is another indicator to be aware of when analyzing a URL.
Phish Site Testing Setup
Before moving forward with testing, I like to make sure I have my OPSEC in place. You will see why this was important right off the bat.
The setup included the following steps:
- Set up my host-based VPN client
- Use a separate Linux virtual machine
- Use a TOR browser on the virtual machine
- Use browser User Agent changer
- Enable TOR-based routing on the virtual machine
These measures are all critical to assist in concealing the true source location of your connections if you are testing from a lab off your local host machine. This was important, since I identified from the original phish site landing page source code that it was tracking the source of the incoming connection.
Phish URL Threat Analysis – Mobile vs Desktop
The first thing I noticed during the phish URL analysis was the attacker was specifically targeting mobile-based devices due to the ‘Connection Refused’ error messages I received when using a standard desktop browser.
The first step to successfully connect to the phish page was to spoof the desktop browser User Agent.
Original Desktop Browser User Agent (Failed)
Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
I successfully spoofed the User Agent to look like it was coming from a mobile device. A ‘Safari for iOS’ User Agent was used for all testing moving forward.
Spoofed Browser User Agent (Success)
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1
In order to achieve the browser User Agent spoofing, I used a Firefox plugin called ‘User-Agent Switcher.’ As an alternative, Burp Suite would accomplish the same tasks and route all analyzed traffic through TOR.
Phishing Link Testing Walkthrough
After clicking on the link provided in the text message, a redirect takes you to a landing page stating that the targeted user has a Reward Pending.
After clicking Yes, claim Reward, you would be taken to very rudimentary website that requests critical Personally Identifiable Information (PII), which is the start of the information harvesting.
The requested information is:
- First and last name
- Date of birth
- Mobile phone number
Once this registration process is completed, you would be shown a progress map of your great work. You are now one step closer to full-blown identity theft.
The next step in the process is to complete a survey.
There is no actual survey to complete at this point—it turned out that you had to register for one of the presented deals to get to the next level in the process. The number of steps in this process (in my personal opinion) should have significantly diminished the likelihood of the phish’s overall success.
Once you click on the image, you would be redirected to another page that presents some options of the so-called deals you could choose from. It is here where PII harvesting continues. During the product trial registration, you are prompted to input all of the PII again as well as credit card information to successfully register for the associated trial deals. This final step was not completed, although fake credit card information could have been entered to completely identify the end of the process.
Although this testing did not identify any correlation between the text message phish and the ransomware incident, it did confirm for the client the motive to harvest PII and credit card information.
Defense Measures to Take into Consideration
Some simple defensive steps that can be taken to assist in preventing SMS phish attacks are:
- Do not take the bait, do not click on the link, and immediately delete the text message.
- If you do not recognize the number or email address of the sender, delete the message.
- Do not call any unrecognized numbers within the text message.
- Refrain from storing any sensitive data on your mobile phone. In the event your phone is compromised, this would limit the personal exposure to the compromise.
- User awareness training is key to assisting in general identification and knowledge surrounding these types of phishing attacks.
Indicator of Compromise (IoC) List
This text-based phishing incident targeted a single high-value corporate user, but it is easy to see that the victim could have had their personal identity stolen. Further, there is a high probability that a credential stuffing attack could have been launched against the organization using the victim’s name and credential information harvested from the text-based phish attack.
Once again, it pays to dig deeper and unravel the analysis threads to understand the threat posed—not only to the impacted individual, but to the organization as a whole.