Notes from the Field • 10 MIN READ

QR Code Vulnerabilities: Dissecting New Techniques Seen in the Wild

by Darshan Thakkar, Nikhil Kurkure • Oct 2023

SecurityHQ analysts have recently observed a significant increase in Business Email Compromise (BEC), regarding phishing attacks containing QR code (Quishing) and captchas for credentials harvesting.

This blog aims to highlight the sophisticated nature of this attack, to understand the technical aspects of session abuse, and its prevention.

What is Quishing?

In the ever-evolving landscape of cybercrime, threat actors are constantly discovering new methods and using them to target organizations. One such emerging threat is known as ‘quishing’ or QR code phishing. Quishing attacks usually occur via the scanning of a QR code. This technique involves tricking organizations users into scanning a QR code using a mobile phone. The QR code then redirects the user to a phishing or fake website that aims to steal their credentials.

Why Are QR Codes Being Used?

In the past, attackers used various types of URLs and attachments to deliver phishing emails. But, due to advanced email gateway security controls, bypassing the email gateway is not an easy task.

One of the main reasons why threat actors choose the QR Code is because it’s the simplest way to force a user to move from a desktop or laptop to a mobile device, which usually don’t have any anti-phishing protections. Additionally, they have multiple advantages over a phishing link embedded directly in an email.

Another reason is these phishing emails are easily getting through the email security gateways because currently email gateway sandbox is not capable to scan QR code and provide the verdict on whether it is phishing or not. Due to a lack of inspection from email security gateways, attackers are taking advantage and more commonly targeting users with QR code phishing technique.

How Quishing Attacks Work?

The attack begins with an email that claims the recipient must take action to update/view their organizational account settings. These emails carry PNG, JPEG, GIF, or attachments containing a QR code. The recipient is prompted to scan to verify their account. These emails also show an urgency to act within 2-3 days in the email subject such as “Urgent”, “Important”, “2FA” and tricking the user sending emails related to ‘salaries’, ‘increment’ and ‘appraisals’ etc.

The QR codes in this campaign also uses redirects in well-known domains such as Baidu, GoDaddy, and IPFS, etc. URLs to send the targets to a Microsoft 365 phishing page to evade security.

Figure 1 IPFS URLs Used in the Phishing Attacks.

The redirected URL is hidden in the URL using base64 encoding, this helps them to evade detection and get through email protection policies.

Figure 2 Screenshot of URL Using IPFS for Redirection & Impersonating Fake O365 Login Page.

After entering the credentials these are being sent to a newly created random 34characters domain, and using this information users account are getting compromised.

Figure 3 Payload Containing the Actual Phishing URL.

Scenerio1:

An email claiming to be from Microsoft app support asking the recipient to reauthenticate the 2FA to avoid being locked out (stating urgent action required).

Figure 4 Sample1:- Email Containing QR Code Impersonating to be from Microsoft.

Scenerio2:

An email appeared from the organization’s doc store tricking users to view their updated salary increase by specifically asking users to scan the QR code from the smartphone camera to evade security controls via workstation/Laptop.

Figure 5 Sample 2: – Email Containing QR Code Impersonating to be from Organisations Doc Share.

What is a MiTM Attack?

A ‘Man in the Middle’ (MiTM) is an attack where a malicious actor eavesdrops on the communication between clients and legitimate server. Regarding phishing, attackers are now using newly built phishing kits available on the Dark Web, like Evilginx, with reverse proxy being used to intercept email addresses, credentials, Multi Factor Authentication (MFA) code and session cookie.

We have observed this attack technique utilizes cloud services for hosting phishing servers, which aren’t sandboxed by the majority of email gateways and/or hosted on reputed cloud service provider as per threat intelligence.

How Does the MiTM Phishing Attack Work?

Taking into consideration that the email has been delivered to an end user’s Inbox folder and the user has clicked on this URL.

Figure 6 AiTM Phishing Progress. Source: Microsoft.

The malicious emails contain URL hosted on Google Docs URL which are clean reputed, hence sandboxing of email gateways won’t categorize such URLs as phishing. This redirects to phishing domain containing credential harvesting authentication forms which are behind Cloudflare captchas.

Figure 7 Google Servers Hosting Original Email URL.

Figure 8 Screen Showing Phishing Sites Hosted on CloudFlare.

Figure 9 Phishing Page Identified Only Through URL Domain.

With new techniques provided by phishing kits, the login page appears as a legitimate Microsoft genuine portal, except the URL domain is the identifier in such scenarios. To understand how this authentication intercepts the traffic between client and server, here you can see the utilization of Fiddler Classic tool as a proxy.

While simulating, SecurityHQ analysts checked with entering wrong username for M365 logins, but the phishing page validates the entered information through API with M365 in the background and allows redirection if its valid. So ideally, if login URL isn’t reviewed the end user experience would be exact as M365 genuine login.

Figure 10 Image Depicts Incorrect Username Being Checked Against Microsoft Servers from Phishing Site.

Figure 11 API Usage for Username Verification on Phishing Site.

To provide genuine behavior, phishing server captures the M365 company branding for login from M365 servers as bait, to provide end user the feeling as if they are logging into the legitimate portal. From Fiddler, we observe GET request towards ‘aadcdn’ domain for tenant branding image fetching.

Figure 12 Company Branding to Showcase Legitimacy to End Users.

Figure 13 HTTP Queries Towards ‘aadcdn’ Which is a Microsoft Owned Domain for Company Branding Images.

After entering the credentials, which aren’t encrypted towards the phishing server, indirectly it was entered against the M365 AAD servers by the attacker.

Figure 14 Cleartext Password Being Posted Towards Phishing Server for MiTM Attack.

While MFA prompt is the next step for login flow, notice the difference between the current legitimate method used by M365 for my tenant, and that it is through Authenticator app code. Meanwhile the phishing server utilizes the other authentication methods like Text or Call with registered number for the test account.

Lastly, this suggests, that the phishing server is acting as proxy, as authenticator code would be submitted towards to M365 to get session assigned to the end user.

Genuine MFA Prompt:

Figure 15 Official M365 Login Page Prompts for Phone OTP as Authentication Method.

Malicious Page MFA Prompt:

Figure 16 Phishing Page Prompts for Text or Call MFA Codes Towards Genuine Mobile Number Registered with M365.

Here for simulation, SecurityHQ used Text code and received this from Microsoft servers through SMS, suggesting to the end user it’s a legitimate M365 page. After which the session cookie is provided by M365 server to the attacker. This session cookie can be captured and be injected on any browser for persistence. Below diagrams depict how normally a session cookie is available on the browser and how its injection works from an attacker’s perspective.

Figure 17 Types of Cookies from M365 Login Page.

Under ESTSAUTHPERSISTENT, we have the cookie value which is valid for 3 months for 1 session.

Figure 18 Persistent Cookie Value and Expiration 3 Months from Login Time.

Here is the access of the legitimate M365 login page to inject the session cookie on a different machine.

Figure 19 Injection Session Cookies for Persistence.

Figure 20 Injection of Cookie through Inspect Option on the Browser.

Figure 21 Depiction of Cookie Added to Application Option on Browser.

Below, the required cookie is manually added, and then the same page is refreshed.

Figure 22 Manually Adding New Cookie for Persistence on M365 Official Login Page.

After refreshing this page, logins work, bypassing MFA and security controls, and the attacker is allowed to login to the same Office home application without MFA.

Figure 23 Persistent Cookie Being Added Manually.

Once the attacker gets the session cookies provided by M365 for the account, the user lands on a webpage showing error prompt depicting the login failed, while the attacker logs on, on the users’ behalf. M365 has captured the session cookies and from Azure AD sign-in logs, and login is noticed from USA IP.

Figure 25 Landing Page After Attacker Gets Session Cookie from M365.

Figure 26 M365 Audits Logs Depicting Attacker Successful Logins.

Mitigations

Implement detection use cases to monitor and alert login anomaly. SecurityHQ solutions have different layers of use cases that can detect and respond to such anomalies reducing the dwell time.
Ensure Email and web gateway policies are hardened to block such innovative phishing attempts.
Create awareness among the users around ever evolving phishing tactics and stay up to date against the new campaigns seen in the wild.
Implement conditional access policies to not allow logins from noncompliant host, non-business locations and unusual user agents. In case of credential leakage CAS policies will help you to prevent successful login from attackers.