Greg Foss
Security Operations Team Lead

How Far Cyber Criminals Will Go to Get Your PII

Notice: LogRhythm always recommends using a sandbox or other “safe” method when testing or investigating known malicious sites.

Phishing for Personally Identifiable Information (PII)

Everyone who works in security deals with phishing emails to some extent—some more than others. In fact, most of us in the security industry see so many phishing attacks on a daily basis that they are not all that interesting anymore.

However, every once in awhile, a scammer will actually take the time to prepare and deploy more believable campaigns and target personally identifiable information (PII) in a more persistent way.

One campaign that I recently investigated appears to be sent in a much more targeted manner. In fact, I only observed a single copy of this message being sent to one user (or anything else from the sender / domain / etc.) per-company in a 24-hour period. The message appears to be sent through a compromised website.

Click images to view larger

Figure 1. Message Sent through Compromised Website

Let us look at this attack in more detail. The email itself has all of the standard characteristics that you would expect from a phishing attack. In the notice of “immediate action required,” all of the links point to the same location, and most obvious, the recipient did not have an account with this institution.

Figure 2. Account Notification Phishing Email

As previously mentioned, a typical trait of phishing emails is that all the links are the exact same. Clicking on any of these sends you to another compromised website that has a newly registered subdomain, likely unbeknownst to the site owner.

Once you hit the first page, it redirects to another subdirectory where the phishing web pages are hosted. This dynamically guides the user depending on their User Agent string (UA) and assigns them a unique token that is used for tracking on the criminal’s end.

When curl or similar “inspection” USAs are used or the second subdomain is accessed directly, then no token is generated and no content is returned. Often attackers will do this as a way to deter forensic analysis of the contents of the page.

This can also be used to direct the end-user to different web pages depending on the browser they used to access the content—many times deploying different attacks depending on the user agent string. Criminals think this is sneaky, but it really does not hide anything at all. In order to circumvent the attacker’s controls, the analyst only needs to change their User Agent string to test such content.

Figure 3. Change User Agent String to Test Content

When you load the page in a browser, it does not contain any malicious JavaScript or similarly dangerous content—only a fake login screen. As you can see, the malicious site does not use a SSL—a strong indicator that it is not legitimate.

That said, there are easy ways for anyone to obtain a valid SSL certificate for free from sites such as letsencrypt and startssl. While these sites offer an incredible service that will provide a significant amount of security to the internet as a whole, the ease at which one could generate and install a free TLS certificate on just about any website will undoubtedly raise the bar for phishing attacks.

Figure 4. False Login Screen

Upon “logging in” to the application, the form processor likely writes the “account information” out to a text file. It may be sending an email as well, but it is difficult to confirm solely on the client-side code and additional information readily available for analysis. Sometimes (not all that often anymore), you can intercept emails as they are processed on phishing pages; however, most attackers are aware of this and compensate accordingly.

Figure 5. Account Information from Form Processor

After completing the first form, the user is sent to a second “authentication portal” where they enter all of their challenge questions. This is key, as it is likely that many of these challenges are used elsewhere, and they may provide the attackers with much more access than just their account—although that is a juicy target by itself.

Figure 6. Verify Challenge Questions

From here, they promptly go for the entire identity.

Figure 7. Confirm Your Information PII Entry

All they really did was clone the homepage and subsequent account creation pages so it looks legitimate and transformed it into a “verification” set of pages with their own custom form processor on the back end.

Therefore, the attack itself is not complex at all. However, the information that they could potentially gain, assuming this works, is significant. The combination of the victim’s back account credentials, security questions, full social security number, name, phone number, email, password and additional personally identifiable information could not only allow an attacker to empty their victim’s bank account, but also assume or sell their identity (not to mention gain access to other accounts).

The Final Stage of the Attack

Once the victim fills out the form, it redirects back to the credit union’s actual homepage. When comparing the attacker version of the site and the current credit union site, you will notice a substantial difference in theme and layout. This is an indication that the scammer created this attack some time ago.

Figure 8. Comparing the Attacker Site with the Actual Credit Union Homepage

Using historical information from DomainTools, I found that their registration data is not masked behind a private registration proxy, nor was it ever that way. It was also not transferred to another user in many years.

By reviewing their whois history, you can tell that this is most likely a legitimate website that has been compromised. The top-level domain has been active since 2011 under the same owner and has maintained a good reputation up until now.

Figure 9. Domain Whois History

Using PassiveTotal, we are able to tell that the malicious subdomains were added in April 2016. This shows us when the site was most likely compromised and the attack pages were injected. Therefore, given what we have found thus far, I figured it would be best to tag this domain so that others can potentially be notified.

Figure 10. Tagged Domain for Future Notification

The additional subdomain was added even more recently—just a week before I began this investigation. I am guessing that their original subdomain may have been flagged, so they added this on and built in the redirect. Or maybe its only purpose is to evaluate user agent strings and redirect accordingly (but I am probably just overthinking things).

Figure 11. Tagging the Additional Subdomain

The execution and various other aspects of the attack made this more intriguing than many of which we investigate on a daily basis. The attacker took the time to compromise multiple legitimate websites in various countries, cloned content from the legitimate website, implemented custom form processors, staged relatively believable content, created a reporting mechanism, and selectively phished specific people in a targeted manner—all for a chance to gain access to someone’s PII.

Scammers are constantly working to improve their methods to gain access to sensitive information, so as defenders, we must do the same in an attempt to keep them out and warn our counterparts in the industry. The challenge is that phishing is a tough problem to solve.

As much as you can train users and automate the analysis, blocking, response, and categorization of the various attacks, there is always the risk of phishing attacks (such as this one) making it through, as they don’t contain malware and are not sent to a wide range of users. All the attacker needs to do is research and select the right targets once the foundation has been laid.