Overview
Proofpoint researchers recently observed a phishing kit with peculiar encoding utilized in a credential harvesting scheme impersonating a major retail bank. While encoded source code and various obfuscation mechanisms have been well documented in phishing kits, this technique appears to be unique for the time being in its use of web fonts to implement the encoding.
When the phishing landing page renders in the browser, users are presented with a typical online banking credential phish leveraging stolen bank branding. However, the source code of the page includes unexpectedly encoded display text (Figure 1)
Figure 1: Code snippet from phishing landing page with displayed text encoded despite decoded rendering
Copying the cleartext from the webpage and pasting it into a text file still results in encoded text.
The text can be decoded through a straightforward character substitution cipher, making detection of the phishing landing page simple for automated systems. However, the implementation of the substitution in this case merits closer examination.
Substitution functions in phishing kits are frequently implemented in JavaScript, but no such functions appeared in the page source. Instead, we identified the source of the substitution in the CSS code for the landing page (Figure 2).
Figure 2: CSS @font-face rule from the phishing landing page source code
After reviewing many copies of the phishing kit left behind by the threat actors, we know that the ../fonts/ directory does not exist in the kit, making the base64-encoded woff and woff2 the only loaded fonts.
If we extract, convert, and view the woff and woff2 web font files, we see the following font specification:
Figure 3: “woff” font specification
This phishing landing then is utilizing a custom web font file to make the browser render the ciphertext as plaintext. As the Web Open Font Format (WOFF) expects the font to be in a standard alphabetical order, replacing the expected letters "abcdefghi..." with the letters to be substituted, the intended text will be shown in the browser, but will not exist on the page.
It is also worth noting that the stolen bank branding is rendered via SVG (scalable vector graphics), so the logo and its source do not appear in the source code (Figure 4). Linking to actual logos and other visual resources can also potentially be detected by the brand being impersonated.
Figure 4: Code snippet showing SVG rendering of stolen bank logo
We first observed the use of this kit in May 2018, but it is certainly possible that the kit appeared in the wild earlier. Most archive dates on resource files we have observed in samples of this kit are dated early June 2018.
Conclusion
Threat actors continue to introduce new techniques to evade detection and hide their activities from unsuspecting victims, security vendors, and even from savvy organizations proactively searching for brand abuse. In this case, actors developed a phishing template that uses a custom web font to implement a substitution cypher, among other techniques, to render well-crafted phishing pages for credentials to a major US bank. While the substitution cypher itself is simple, the implementation via web font files appears to be unique, giving phishing actors yet another technique to hide their tracks and defraud consumers.
Indicators of Compromise (IOCs)
We identified several email addresses associated with the phishing kit, both within the PHP source code and hard-coded as recipients of stolen credentials. These addresses included:
fatima133777@gmail[.]com
fitgirlp0rtia@gmail[.]com
hecklerkiller@yandex[.]com
netty6040@aol[.]com
nicholaklaus@yandex[.]com
oryodavied@gmail[.]com
realunix00@gmail[.]com
slidigeek@gmail[.]com
zerofautes@outlook[.]com
ET and ETPRO Suricata/Snort Signatures
Coverage for this threat is available in the ETPRO Ruleset.
Subscribe to the Proofpoint Blog