Red Canary began to see its annual spike in credential harvesting attacks last week. These attacks typically increase as tax season approaches and adversaries gear up to file fraudulent tax returns. Here’s what organizations need to know to understand and mitigate the risk.
How Credential Harvesting Works
Adversaries send the victim a personalized lure, which is typically an email containing a plausible subject, such as “Red Canary invoice” and a hyperlink. The hyperlink may be within the email body or within a benign attachment (i.e., a non-weaponized PDF) and leads to a login page associated with a service that the victim is known to use. The most common are Office 365 / OneDrive, Google Drive, and Dropbox.
The login page, naturally, is a fake. Adversaries compromise sites operated by unwitting third parties and use them to host a single page that looks as expected. When the victim “logs in,” their credentials are immediately captured in the clear and provided to the adversary for re-use. The adversary then leverages those credentials to access another system aligned with their objectives. In some instances, the victim receives a file that aligns with the document they were expecting, in hopes that it will make them less suspicious of an attack.
Common Objectives of Credential Harvesting Attacks
In the enterprise, there’s an assumption that we protect credentials because they’ll be leveraged to access enterprise resources. This absolutely happens, but it is not the objective in most cases. Most attacks are aimed at near-immediate monetization. Corporate espionage is monetizable, but not at the speed nor the volume associated with opportunistic attacks.
One evergreen objective is access to payroll self-service. In 2017, one of our customers was the victim of a highly targeted credential harvesting attack. Upon discovery of the attack, we were able to immediately scope the incident and block the infrastructure. The customer reset passwords and verified that none of their enterprise systems had been misused or accessed during the compromise window associated with each account. All of the affected accounts were carefully monitored for a period of time to ensure that nothing was missed. The adversary, however, did an end run around enterprise infrastructure altogether and reused credentials to log in to the customers’ third-party payroll provider, using self-service to change direct deposit information. Almost two weeks later on payday, the attack came home to roost.
This time of year in particular, adversaries seek access to payroll and benefits self-service for a different reason: The information found in these systems is typically all that’s needed to file a fraudulent tax return.
Detecting Credential Harvesting Attacks
This is a unique class of attack, in that technical controls are of limited utility. For organizations with robust ingress filtering and inspection, there is some hope.
URL sanitization services may help, provided that the attack infrastructure is known or contains attributes that allow it to be flagged. But in most cases, adversaries co-opt legitimate sites because those domains are “seasoned.” Newly observed domain names are great candidates for blocking or scrutiny, depending on your aversion to risk. By using established domains with good reputations and search engine results, the adversary avoids being blocked for an obvious reason.
The email lure typically includes a link instead of an attachment, or includes a completely innocuous attachment. No attempt is made to deliver malware. From an endpoint perspective, the only observable “behavior” is a browser visiting a website, which we see millions of times per day.
Detection relies heavily on user awareness. In almost all cases, this class of attack is self-reported by one or more victims.
Attacks that are not self-reported by a victim are detected through deliberate inspection of the URLs found in inbound message traffic, both message bodies and attachments. The major providers in this space are able to do things like visit pages and use machine analysis of the pages to identify things that look like or contain login forms, and then protect their entire customer base from these sites at once.
The good news is that, because of how these are perpetrated, they can be effectively mitigated once indicators are known.
How to Respond
Given an indicator, such as the domain and/or IP address associated with a fraudulent login page, our playbook for these attacks includes prevention, scoping of the incident to date, and rapid response to future potential instances.
Let’s dig deeper into these three elements.
Job number one is preventing additional endpoints from communicating with the fraudulent login page. Our new OpenDNS integration, as one example, makes it easy for shared customers to immediately prevent all endpoints from visiting the offending domain. Blocking based on IP address as well protects against the adversary using new domains or none at all once the attack is in flight. This can be done with any set of tools, or it can be done manually. But the fact that it gets done quickly is of utmost importance.
We scope attacks by using endpoint telemetry to answer the questions:
Which users clicked through to the fraudulent login page? This identifies potential victims.
Which users submitted credentials? This isn’t a perfect science, but can often be determined by baselining the number of network requests associated with a visit versus a form submission. This identifies likely victims.
Which endpoints received the file promised in the lure? This is a much better indicator of successful harvesting, as the file typically isn’t delivered until credentials are supplied. This identifies confirmed victims.
Additionally, despite the fact that that most of these attacks are opportunistic and no attempt is made to compromise enterprise systems, we make no assumptions. Simplified views such as mapping of user accounts to endpoints (as shown below) can help to identify any case where enterprise systems are misused.
We use our endpoint-based collection platform to set up direct alerting to the customer as new potential or confirmed victims are identified using the techniques above. Unlike most of our detection notifications, these bypass the SOC and are fed directly to the team responding on the ground. Again, any organization can implement this provided that they are collecting the right data and processing it in a manner that facilitates these activities.
Mitigating the Risk
While there is no foolproof prevention, there are steps organizations can take to mitigate the risks of credential harvesting. These include:
Multi-factor authentication (MFA): MFA is the single most effective safeguard against compromised credentials, regardless of the method of compromise, and should be standard practice for all organizations. Should an employee inadvertently disclose their credentials, MFA ensures that they are of limited utility because the adversary doesn’t have access to the device used to provide the second factor (commonly time-based one-time password, or TOTP). This assumes that credentials aren’t being reused across multiple services. If poor password hygiene is in play, then the risk is greater because the adversary may seek out additional services that are not protected by MFA.
Anti-phishing training: Educating your organization’s employees on the risk of phishing is always important, but it’s especially crucial during “high attack” periods like tax season. Remind users to be wary of any email that they aren’t expecting, doubly so if there are any attachments or links.
Collect endpoint telemetry: Be prepared for attacks that do bypass your controls, and that aren’t identified by users until it’s too late. Collection of endpoint telemetry is a huge advantage in these cases, as you are well positioned to use process, network, file system and other forensic data points to detect, scope, and respond. This follows the adage that prevention is ideal, but detection (and response) is a must.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.