Overview
Today’s CISOs are trying unsuccessfully to mitigate the threat of malware and credential theft, the two greatest risks associated with email. This is due, in large part, to the difficulty in detecting and preventing targeted spear phishing attacks.
The spear phishing vulnerabilities stem from the fact that legacy email security solutions, including sandbox-based anti-phishing products are largely based on reputation, that is, whether an email link is known to be “good” or “bad.” A link’s reputation is determined via third party data feeds, or internally by way of large- scale email traffic and data analysis.
In the case of spear phishing attacks, which target specific individuals within an organization, the email link is usually unique, as is the target user, hence there is no third party reputation data available, nor is there enough data to analyze internally to make an accurate determination. If the determination is incorrect, even with a sandbox, users are sent directly to a site where credentials can be stolen, or malware can be downloaded to an endpoint.
Menlo Security’s researchers recently uncovered such an attack at a popular enterprise that went undetected by existing security solutions. A close examination of this spear phishing event revealed interesting details. The attackers:
Performed various checks on the password entered by the victim and their IP address to determine whether it was a true compromise vs. somebody who had figured out the phish
Supported various email providers. This was determined by the fact that they served custom pages based on the email domain. For example, a victim whose email address was john.doe@gmail.com, would be server a page that looked like a gmail login page
Exfiltrated victim’s personally identifiable information (PII) to an attacker controlled gmail account. At first, this attack did not look any different than common credential phishing campaigns. But Menlo’s researchers were able to gain additional insights into the attacker’s operations.
Anatomy of the Attack
The credential phishing URL, sent to the unsuspecting victims was of the format: http://www.evil.com/owa/index.php?username=john.doe@domain. com, where the username field was populated with the victim’s email address.
If the victim clicked the link, he or she would be presented with a page that looks like the one in Figure 1..
The page that was presented depended on the domain name present in the username parameter in the URL above. In Figure 1, since the domain is gmail. com, a gmail login page was presented to the victim.
Figure 1
The domains mentioned below were supported as part of the phishing campaign.
• @yahoo
• @rocketmail • @ymail
• @live
• @hotmail
• @msn
• @gmail
• @google
• @aol
• @aim
If the victim’s email domain names matched any of the domains above, a specific page would be presented. For instance, if the domain was yahoo.com, then relevant scripts were executed to serve a page that looked like the login page of yahoo mail.
If none of the domains matched, a generic webmail page similar to the one in Figure 2 was presented to the user.
Figure 2
The Importance of Scripts
The attacker relied heavily on several key scripts to execute the phishing campaign.
INDEX.PHP
The index.php script performed numerous checks on the email and password fields entered by the victim to verify its validity. The function is_rubbish, shown in Figure 3 below, is an example of the checks that were done on the password field. If the password and email fields passed validation checks, the page was redirected to another script named log.php.
Figure 3
LOG.PHP
The log.php script imported a library known as “block_detectors.php”. The primary functionality of the log.php script was to send the PII stolen by the attacker to an attacker-controlled email address.
BLOCK_DETECTORS.PHP
This script was responsible for checking to see if the IP address from which the victim was connecting matched a list of IPs, shown in Figure 4, specified by the attacker. The script also looked to ensure that the host name did not contain any of the strings listed in the Figure 5.
Figure 4
Figure 5
This script was also responsible for obtaining the following information about the victim:
- Victim’s IP Address – The script accounts for requests coming from proxy environments. If the “HTTP_CLIENT_IP” or “HTTP_X_FORWARDED_FOR” headers were present, the client IP address was extracted from those headers. If not, the ‘REMOTE_ADDR’ parameter was used to get the victim’s IP address.
- Victim’s Country & City – The script made a request to “http://www. geoplugin.net/json.gp?ip=”, with the victim’s IP address and extracted the country name and city information from the JSON returned by geoplugin. Below is an example of a JSON response from geoplugin
Figure 6
- Date & Time – The date and time the victim connected to the attack domain
PAGE2.PHP?
The victim was also presented with a page to enter his or her phone number and alternative email address to confirm the victim’s identity. If the victim entered these details, the page2.php scripts validated the phone number and the email address and redirected the user to the actual login page of the vendor.
How Successful was this Campaign?
Menlo researchers were able to discern that between 50 and 100 victim credentials were stolen the day the domain was established. It was just one of five domains that were utilized in this campaign:
• koservint.com
• upgrade-emailexchange.ml
• upgrade-emailquota.ml
• mailbox-upgrade.ml
• upgrade-emailexchangequota.cf
Based on these findings, Menlo Security estimates that an attack such as this one can net as many as 100s or 1000s of targeted high-value credentials each day the phishing campaign is active.
