QR Code Vulnerabilities: Dissecting New Techniques Seen in the Wild

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.

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

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

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).

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.

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.

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.

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.

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.

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

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:

Malicious Page MFA Prompt:

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.

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

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

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

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.

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.

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.

Speak with a SecurityHQ analyst, to learn more, here.