ANATOMY OF A SPEAR PHISHING ATTACK. A Menlo Security Research Report

Size: px

Start display at page:

Download "ANATOMY OF A SPEAR PHISHING ATTACK. A Menlo Security Research Report"

Shonda Wood
6 years ago
Views:

1 ANATOMY OF A SPEAR PHISHING ATTACK A Menlo Security Research Report

2 Overview Today s CISOs are trying unsuccessfully to mitigate the threat of malware and credential theft, the two greatest risks associated with . 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 security solutions, including sandbox-based anti-phishing products are largely based on reputation, that is, whether an link is known to be good or bad. A link s reputation is determined via third party data feeds, or internally by way of largescale traffic and data analysis. Menlo Security s researchers recently uncovered a spear phishing attack at a popular enterprise that went undetected by existing security solutions. In the case of spear phishing attacks, which target specific individuals within an organization, the 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 providers. This was determined by the fact that they served custom pages based on the domain. For example, a victim whose 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: com, where the username field was populated with the victim s 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. 2

3 Figure 1 The domains mentioned below were supported as part of the If the victim s 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 3

php script performed numerous checks on the email and password fields entered by the victim to verify its validity.

4 The Importance of Scripts The attacker relied heavily on several key scripts to execute the phishing campaign. Menlo researchers were able to discern that between 50 and 100 victim credentials were stolen the day the domain was established. INDEX.PHP The index.php script performed numerous checks on the 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 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 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 4

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 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. 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 address to confirm the victim s identity. If the victim entered these details, the page2.php scripts validated the phone number and the 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- exchange.ml upgrade- quota.ml mailbox-upgrade.ml upgrade- exchangequota.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. 934 Santa Cruz Avenue Menlo Park, CA Tel: info@menlosecurity.com 2017 Menlo Security. All rights reserved.

Censornet. CensorNet Unified Security Service (USS) FREEDOM. VISIBILITY. PROTECTION. Lars Gotlieb Regional Manager DACH

Censornet. CensorNet Unified Security Service (USS) FREEDOM. VISIBILITY. PROTECTION. Lars Gotlieb Regional Manager DACH Censornet CensorNet Unified Security Service (USS) FREEDOM. VISIBILITY. PROTECTION. Lars Gotlieb Regional Manager DACH Censornet???? Former SMS passcode. One of the leading vendors in Multi factor authentifaction!