Investigating QR Code Phishing Campaigns and Evasion Techniques
QR codes have become a popular phishing method of choice for many reasons, which has made blocking and defending against this technique a little cumbersome for IT and Security administrators.
Firstly, they are capable of bypassing some email security controls because they’re attached as PNG/JPEG images, and unfortunately, some of those controls are not capable of scanning QR codes to determine its legitimacy.
Secondly, employees will inevitably use their personal mobile devices to scan the QR code, therefore completely negating the security controls usually offered on a coporate machine. Combine the QR code with a legitimate URL redirector like Bing’s (discussed later), it makes it nearly impossible for an employee to establish if the link is malicious or not.
Malicious QR codes in action
Take the example below (QR code has been replaced for OpSec). Although there are many red flags in the email, the ‘DocuSign’ template can still be somewhat convincing to employees.
When analysing phish like this, I like to upload them to a private task in ANY.RUN for automated QR code detection. You can read how it works here - Automatically Detect QR Codes
After uploading the original email, ANY.RUN does a great job at detecting QR codes immediately, whether they are embedded directly inline or attached as a file. All you have to do is navigate to the Outlook parent process and find the file that contains that QR code. In this example, it is an image type as highlighted by the red rectangle below.
Here we can view additional details about the image and particularly the QR code. ANY.RUN identifies it is a JPEG file.
We can click the QR tab and it will show us where the URL actually goes. In this case, we can pretty much tell it’s not legitimate, however, for certainty we can click the ‘Submit to analyze’ button which will launch a new task and open a browser to that URL automatically (pretty neat).
The ‘srvtrck.com’ domain merely acts as a redirect to the phishing landing page. It is used for marketing/advertising tracking, however, it is known to be used with adware and for malicious redirects as shown below.
After the redirect, we are taken to a Russian domain where there is a Cloudflare Turnstile checkpoint. This is used to prevent bots/scanners (urlscan.io) coming across the phishing page and to prevent it being blacklisted from browsers (Chrome’s Safe Browsing and Microsoft’s SmartScreen).
After the challenge is accepted, we are then presented with the phish which is a typical Microsoft credential stealing page.
Evasion techniques and Bing URL redirects
Unlike the example above, I have witnessed some better attempts to evade from bots/scanners as well as human analysis. In this second example below, the phish is another DocuSign template, however, it’s attached as an image instead.
But, the URL used in the QR code is actually a legitimate Bing URL redirect. This is important because an employee will think it’s a genuine link to Bing when scanning the code using the default camera app on an iPhone for example.
Notice in the image below, the iPhone camera app will only show ‘Bing.com’ as the destination of the QR code, making this much harder for your average employee to spot and think twice.
When following through to the Bing URL redirect, the connection to the final destination is rejected. This is because the phish employs some common evasion techniques such as user agent blocking.
Thankfully, for us human analysts, we can simply change the user agent using a browser’s dev tools in Network conditions. As this is a QR code phish, it’s common sense to assume they are only expecting mobile specific user agents. In this situation, I selected the ‘Safari - iPhone iOS’ user agent and then refreshed the page.
After changing the user agent and refreshing, the redirect now follows through properly and we can see the phishing page. Again, another method to prevent bots/scanners is deployed using a custom CAPTCHA challenge.
After checking the box manually, it then redirects again but this time we land on a legitimate Office 365 encrypted message page. This is because the phish employs multiple hoops to confuse automated scanners and make it much harder to detect as malicious by using legitimate services like this.
Fortunately for us in this instance, the encrypted message failed and was not delivered correctly. But, this is a common phishing technique which has been documented by several researchers as explained in the following blogs, so feel free to read those to understand what the next stages of the phish are.
In summary, they end up redirecting to other legitimate sites like Adobe, only for it to redirect once again to the malicious page which is designed to steal credentials.
Indicators of compromise
Domains:
srvtrck.com
mallgy.ru
referal.biz
00000001d0cs1gn000.live
Senders:
ziggo.nl
botoffice.net
