Threat actors have been attempting to subvert security measures by hiding malicious URLs withing QR codes for years now. As we know, threat actors are constantly evolving their tactics, and recently, we have observed intriguing new techniques involving QR codes in email attacks. Traditionally, QR codes are found in embedded images, attached as images or within other attachments like PDF. However, one group has started sending HTML-generated versions.

For instance, a DHL-branded attack utilized HTML trickery by combining lower half block, upper half block, and full block characters with non-breaking spaces. Both phones and online decoders easily recognized and decoded the QR code, leading would-be victims to the malicious URL. This tactic aims to bypass email filters' image QR recognition and URL extraction capabilities.

If the user scans the QR code, they will be directed to a site containing live user verification measures by having the recipient manually type in their first name.

Once that is done, they are redirected to the actual phishing site that attempts to capture any active sessions. If no sessions are active the user is presented with a credential prompt. Once credentials have been gathered the attackers will leverage the account to conduct any number of attack types.

Another more recent html QR attack that was posing as a OneDrive notification also used the same lower, upper, and full block characters separated by non-break spaces. However, we noticed this actor had added obfuscation by varying sizes and widths of the html QR code. In addition, two out of the three online decoders we tried did not recognize it as a QR code while our mobile devices still did. Whether intentional or not obfuscation is a means to defeat some security solutions and tools used to decode the malicious URL within, while achieving their objective by getting the target on their mobile device where security controls are typically less ubiquitous.

If the QR code was followed, the recipient would have to complete a color-matching live user verification step. Once completed, they would then be routed through Cloudflare’s live user verification turnstile as a second check.

After the live user was verified, they are redirected to the AiTM phishing site that initially attempts a reverse proxy token theft. If no active session token is available, they would go thru standard MS 365 authentication procedures – password / MFA prompts (if enabled) then the attacker would be able to steal the session token while simultaneously stealing credentials for future action, including password reuse attacks across other services.