The Anatomy of a Lazy Phish

Phishing is one of the most effective ways hackers can compromise a network. Instead of requiring the skills and time to target specific organizations, perform reconnaissance, discover vulnerabilities, and select attack vectors, attackers can indiscriminately blast out phishing emails and wait for users to be tricked into submitting their credentials to a phishing site. I recently came across a phishing page that shows the interworkings of a phish and just how easy it is for unskilled and lazy attackers to host a credential harvesting page.

Like any phish, this starts with an email that appears to be from a reputable source and sends the recipient to a malicious site. In this case, the link directs to a page that is designed to look exactly like Microsoft's online login page, where the user is asked to enter his or her username and password. After all, this is exactly what the attacker wants — the user's credentials.

So far, this is a standard phishing attack. The attacker sends a link in an email to trick the end user into visiting a phishing site that aims to steal the user's credentials. But I didn't stop there. I wanted to see what else could be found on this website, so I navigated to the homepage of the site and discovered the following:

Credential Harvester Directories

Above, we see the directories and contents of the credential harvester left by the attacker on their publicly accessible home page. Drilling into the "new" folder within this directory, I discovered that the attacker left their entire exploit source code in a zip file titled "bless.zip." Fully extracted, this zip file holds various .php files that contain instructions for the login process on the phishing site and for blocking certain clients from accessing the webpage. Further examination of this source code shows exactly how the attacker siphons user information, and who they're trying to prevent from viewing their site.

In the action.php file below, we see what happens when a victim submits credentials to this phishing site.

The .php code records the user's IP address; performs a geolocation lookup on the IP address to determine its country of origin; and records the date and time of access, the user's browser type, and the username (or phone number) and password that the user submits to the phishing page. The $sent variable reveals the email address where the attacker sends credentials, tailored to this specific phishing campaign to hide the attacker's personal identity. The email $headers variable contains the sending email address for this credential harvester: wirez[@]googledocs[.]org. A DuoLabs report that analyzes phishing kits at scale suggests that this sender address appears in more than 115 unique phishing kits.

Examination of the other .php files shows additional information about the exploit kit. In the file block.php, the kit specifically checks for keywords in the hostname of clients visiting the site. Terms such as "phishtank," "google," "trendmicro," and "sucuri.net" in the client hostname will result in the exploit kit sending the client to a 404 Not Found page rather than the impersonated Microsoft login site. This code aims to prevent security-oriented organizations from accessing the exploit page and identifying it as a phishing site, and thwart users visiting from cloud-based services from accessing the site. The file includes 568 IP addresses that are blocked from viewing its login page.

The content of the examined .php files and the fact that they were publicly accessible on the homepage of the phishing site demonstrates that this attacker was either not technically savvy or felt that controlling access to their exploit source code and hiding the email account receiving victim credentials was not worthy of their time. In either case, it's a great example of why phishing is so dangerous: It takes minimal effort and skill on the attacker's end and only one user to fall victim to the attack to effectively compromise an organization.

There's no one technical solution that can prevent all phishing attacks from being successful. What's needed are layers of security structured to prevent the delivery of a phish, detect phishing emails that do make it into an organization, alert security personnel when a phish is delivered, and prevent users from visiting malicious phishing sites.

Most importantly, end users need to be aware of the threat that phishing poses to their organization and empowered with knowledge to determine whether an email is legitimate. When an organization is targeted by an attacker, it will be layers of security and users' knowledge that ultimately determines whether a phishing email leads to a breach, or if the email is simply discarded by technical controls or an informed end user.

Related Content:

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.