Credential harvesting and automated validation: a case study

During our incident response engagements, we very frequently come across phishing lures set up to harvest as many credentials as possible, which will likely be sold afterwards or used in follow-up attacks against an organization (or both). While many of these credential harvesting attacks follow the same pattern, from time to time we stumble upon something new.

Over the last few months we worked on several phishing incidents that followed the next pattern:

1. Phishing mail received by user where the sender is a known contact (who was compromised earlier)
2. Phishing mail contains link to WeTransfer website where an HTML page can be downloaded
3. HTML page displays Microsoft Office 365 login page
4. User enters username and credentials
5. Upon clicking the “Sign In” button, a script sends the entered username and credentials to a PHP page hosted on a likely compromised website
6. The credentials are automatically checked for validity
7. User always receives an error message “Incorrect password, verify your 365 password and sign in again”

While the majority of this attack seems to be rather standard, the automatically checking of passwords by the script on the compromised website is something we did not see before.

Detailed description of the credential harvesting attack

The initial phishing mail is sent to the user from a trusted source, someone they have interacted with before. This is something we see happening very frequently in these credential harvesting type of attacks: once attackers gain access to the mailbox of a user, they will send a new phishing mail to all users in the “Suggested Contacts” list (this list contains the e-mail addresses of people who you interacted with before). This creates a sense of legitimacy with the recipient of the phishing mail as it is coming from someone who they know and have interacted with before.

The phishing mails themselves are typically tailored to resemble an invoice or document from the sender company (containing the company name in the subject). The body of the e-mail however is not that spectacularly well crafted and typically only contains a reference to the document to be downloaded from an online portal or, as it was the case here, to a file sharing platform.  

From the file sharing platform, the user can download the attachment, in this example, this was an HTML Page where the name of the file contained the company name of the (compromised) sender of the phishing mail.

After downloading and opening  the HTML page, the targeted user would receive a login screen for Office 365 – a screen we are all familiar with:

Interesting to note here is that this is a static page: if your organization has configured to show your company logo on the authentication screen following you entering your e-mail address, this is not taken into account in this phishing example.

So far, this looks to be fairly standard for a credential harvesting attack, when clicking the “Sign In” button, a script is used to send the entered username and password to a PHP page on a (likely compromised) server:

Irrelevant of whether or not the user entered the correct or incorrect credentials, the phishing form would always display that incorrect credentials are entered

Now, looking into our Office 365 authentication logs, we would immediately see that someone tried to authenticate as the user that entered the credentials in the phishing form. This authentication attempt is happening immediately once you click the Sign In button on the local HTML phishing page, indicating there is no human interaction.

As an attack like this could potentially also be used to bypass multi-factor authentication (authentication is performed from another system using the information provided by the user), we set-up a test account on which MFA was enabled (with no support for legacy authentication protocols). A quick test showed that the attackers did not implement a fallback mechanism that would allow them to pass along the MFA code as well.

A few interesting observations to this attack:

• The authentication attempt happens instantly, there is no human interaction
• The IP address from where the authentication is performed is the IP address of the likely compromised website where the PHP script is hosted to which the username and credentials are posted
• The authentication attempt is performed via IMAP4 with User Agent “BAV2ROPC” (a legacy protocol is used here, likely in an attempt to bypass multi-factor authentication)
• It appears that the script on the likely compromised server maintains a key,value pair of previously entered credentials, the script will only attempt authentication with the same username and password once. When entering a new password for the same e-mail address, another authentication attempt will be performed. This is likely done to avoid too many failed authentication attempts showing up in the logs or locking out the user.

Key takeaways

Attackers who are after credentials are, just like our defenses, constantly evolving. In an attack like this one, where credentials are automatically checked via a script, the attacker does not need to be present all the time, but can come back to the compromised web server they are abusing and collect a list of usernames and passwords which are verified to be correct.

It is highly recommended to enable multi-factor authentication on your user accounts and deny legacy authentication protocols from being accepted by your Office 365 infrastructure. In the majority of cases handled related to phishing, the attack would have been unsuccessful if MFA was enabled.