Hackers Use Fake Google reCAPTCHA to Cloak Banking Malware

The most effective phishing and malware campaigns usually employ one of the following two age-old social engineering techniques:

Impersonation

These online phishing campaigns impersonate a popular brand or product through specially crafted emails, SMS, or social media networks. These campaigns employ various methods including email spoofing, fake or real employee names, and recognized branding to trick users into believing they are from a legitimate source. Impersonation phishing campaigns may also contain a victim’s name, email address, account number, or some other personal detail.

Panic/Bait

With this technique, attackers generate a fake situation to instill a sense of urgency or panic in the victim. A well-targeted, well-engineered false emergency often causes a victim to abandon normal operating security policies, aiding the hacker in the process.

During a recent investigation, we discovered a malicious file related to a phishing campaign that targeted a Polish bank. This campaign employed both the impersonation and panic/bait techniques within an email in order to lure victims into downloading banking malware.

Phishing Emails Used to Distribute Banking Malware

These malicious emails contain a fake confirmation for a recent transaction along with a link to a malicious PHP file.

Bank users receiving this campaign would likely be alarmed by an email asking for confirmation of an unknown transaction. This makes it a bit more unique from the phishing content that we typically find, which often consists of a PHP mailer and file(s) used to construct the phishing page itself. In most cases, it’s just a replica of the login page for whatever institution they are targeting.

Instead, the PHP file used in this campaign serves a fake 404 error page to its visitors that have specifically defined user-agents.

In this case, we see that they are limited to crawlers associated with Google, indicating that the attackers must not be too worried about other search engines. We often see multiple search engines blocked using this user-agent filtering method.

Fake Google reCAPTCHA & Conditional Payload Delivery

If a request passes through the user-agent filter (i.e the user agent is not Google crawler related) then the PHP code loads a fake Google reCAPTCHA using some static HTML elements and JavaScript:

This page does a decent job at replicating the look of Google’s reCAPTCHA, but since it relies on static elements, the images will always be the same unless the malicious PHP file’s coding is changed. It also doesn’t support audio replay, unlike the real version.

The PHP code then determines which form of malware – either a .zip dropper or a malicious .apk – to download to the visitor’s device. To make this determination, the malicious PHP checks the victim’s browser user agent again. If it detects that the visitor is using Android, it prompts a download of a malicious .apk file to the device.

Once the APK is installed after downloading, it can be used for malicious purposes like intercepting 2FA. This is a good example of why 2FA through SMS is discouraged in favor of other 2FA methods.

If the PHP code does not detect an Android device, then another request is sent to the file with the parameter “?down” with the MD5 sum of the time, which prompts a malicious .zip download.

You can find more details about the malicious detections on VirusTotal here.

Conclusion

This type of malware can cause serious headaches for website owners. It doesn’t take very long for anti-virus and other security companies to receive reports of the malicious behavior and send complaints to your web host, causing them to disable your website.

Disabling a website is a very serious matter for a web host. It is done to prevent a website’s continued use in malicious activity, which could lead to the blacklisting of their server IP addresses.

A shared hosting server can host many, many websites across shared IP addresses. Depending on its configuration, a blacklisting of a shared IP can cause problems for other customers whose websites do not contain malware but exist on the same shared server.

The malicious directories used in these campaigns are uploaded to a website after it has been compromised. When dealing with this type of malware, it is important to delete the files contained in a complaint., however; we strongly encourage administrators to scan all other existing website files and database for malware as well. You’ll also want to update all of your passwords to prevent the attackers from accessing the environment again.

We’ve put together a helpful guide for how to clean and secure a hacked website. If your site is sending phishing emails and you need a hand cleaning it up, we’re here to help.