QR code phishing

I’ve been seeing a lot of QR code phishing attempts lately. If you’ve not seen the tactic in your environments, the recipient receives an email, and it asks them to scan a QR code on their phone to authenticate and open the link. Here’s a sample email I received from a colleague in my environment:

The image is the email, except I’ve blurred the QR code and censored out personal information in the email. And, honestly, this is quite a clever mechanism. Attackers know that there are most likely security mechanisms on company-owned and -managed computers that would block this going anywhere. But those security tools aren’t on our colleagues’ phones.

Being curious, I decided to check out where this QR code led. Now before you throw your computers across the room and scream at me for needlessly compromising my own environment, I uploaded the QR code image to a QR code web service and got the plain text version of that code. Nobody was hurt in the process. If someone scanned the QR code, here’s the initial site they would have gone to (with some elements of the URL changed to anonymize this):

https://doportal.documentmailbox.com/RedirectTarget.aspx?Action=EmailRedirect&BrandingID=ConEdison&IdToken=[guid]&CheckSum=[checksum]&TargetUrl=https://super-firefly-8102.on.fleek.co/#[user email address]

The first URL is to a service called documentmailbox.com. That seems to be a legitimate service, but attackers have compromised their APIs to allow redirects to other URLs. We’ve seen that with services like DocuSign in the past. DocuSign’s going to be a valid URL to make it through web filtering in a corporate environment, but super-spammy-site.biz is probably not going to make it through.

After a bit of other stuff, the target URL is hosted by a service called Fleek. Fleek is a service that claims to host websites using “decentralized” and “censorship-free” Web3 protocols, so of course it’s going to be used by bad actors. (Ed. note: we know you don’t like Web3, so save that for later.)

There have been some great write-ups on this exact service being used for phishing attacks similar to this. Over on SystemWeakness.com, Lena has done a fantastic analysis of where these URLs go. And of course, because Web3 is about resisting censorship, there’s no way to report to this hosting company that their site is being used for bad. I’m not going to speculate that this is by design… (Eds.: …)

Anyway, what are some things we can do to manage this style of threat? Obviously, the first thing is to tell anyone in your environment that scanning a QR code in an email to access something is not standard practice. If it is standard practice in your environment, then stop! There’s no legitimate reason why you need to authenticate in this way to share information to your users.

As for technical and administrative blocks, this one’s hard to assess. According to the summary email headers, the email was sent on behalf of someone. That’s not really a reason to block an email. The original email is from a .co.jp domain, so perhaps you could create a mail transport rule to send emails from some TLDs you don’t often see to send them to your users’ junk email folders. But that’s a policy decision that IT administrators would have to make with their respective risk management teams.