Financial Aggregators a Vehicle for Credential Exploitation?

One of the first issues we tackled for customers was detecting and mitigating automated (i.e. “bot) attacks against web applications. As an ex-CISO who struggled with these attacks, I wanted us to build tools that would focus on that initial problem. Since then, we have expanded our product roadmap significantly and increased our scope to help customers extend protection to their whole environment, including mobile applications and APIs.

In the process of deploying our solutions, we see examples of the types of attacks taking place in different customers’ environments and industries daily.

In the coming months, we’ll be writing about what we’ve seen, as there are some takeaways and interesting conversations to be had about what we’ve encountered in real-world environments. Much of our focus will be on specialized tools that are directly designed to support automated attacks.

The issue I’ll cover today involves financial aggregators and is somewhat unusual. As a disclaimer, I don’t mean to criticize anyone in the scenario I’m about to describe, except the criminals who seek to exploit and profit from the system.

In case you need a quick refresher on financial aggregators, they are companies that specialize in aggregating a consumer’s financial data into a single view for reporting and analysis purposes. For example, if I have accounts at Bank 1, Bank 2, and Bank 3, I could use one of these services to deliver an aggregated and integrated view of all my accounts through a personalized portal. The best-known company to offer this service is Mint, now a subsidiary of Intuit. But, there are many others that provide similar services.

In some cases, aggregators utilize APIs provided by a particular financial institution; in others, they scrape the relevant data from web pages. And, to be entirely clear, the largest aggregators have very strong security best-practices in place to protect the data they collect. Of course, all of these services require the user to verify their credentials for any site the aggregator is accessing.

Unfortunately for all concerned, a small number of criminals have discovered that the infrastructures that aggregators use for their operations are largely whitelisted* by the various financial sites that they are pulling data from. If you are a criminal intent on performing credential validation attacks, an aggregator’s platform is an ideal place to piggyback.

Attackers have therefore started using automated tools to bulk upload test sets of stolen credentials to an aggregator to test them. Later, they can log in to the same aggregator with the same tool to determine which credentials in their stolen dataset worked.

Previously, when financial institutions trusted aggregators enough to whitelist them, the transactions were on the whole benign and brought a lot of value to consumers who used the services. The evolving issue now is that the transaction mix from aggregators has changed to be a mixture of both benign and malicious transactions, as criminals exploit the aggregators’ infrastructure.

You could perhaps argue that this isn’t intrinsically a problem – although I’d beg to differ – but what I think is reasonable is that companies need to know about how aggregator services can be and are being abused. Fundamentally, that’s why I’ve written this blog.  Both as a cybersecurity practitioner and a consumer there’s an obvious question that needs answering – “what should be done?”

Obviously, aggregators themselves need to improve how they detect and mitigate automated attacks against their platforms. In the discussions we’ve had with several of them, they are keenly aware of the issue and are working to beef up their own defenses to prevent criminals from being able to piggyback on their services. But it’s not clear how long that will take, nor how effective they will be.  It’s our experience that while the large aggregators are as committed to security best practices as anyone, the smaller ones simply have fewer resources to devote to it (although they do care too).

In the meantime what can financial institutions, who are ultimately responsible for protecting their customers’ data, do?

The answer is not clear-cut. Some automated attack detection platforms, like ours, are capable of spotting the patterns of a criminal attack, even though the attack itself is coming from an otherwise legitimate, and indeed whitelisted, source. But, most commercial solutions today can’t deal with this level of ambiguity, as they are focused on detecting the technical behavior of the source endpoint to determine whether a transaction is coming from automation or a “real person”. In the case of these attacks, there is no signal or context around the endpoint at all, and by definition an aggregator uses nothing but automation.

So, apart from finding and using a solution like ours that is capable of spotting that very subtle signal, companies don’t have many choices. Companies could start pressing harder on aggregators and threaten to cut off their preferred (whitelisted) status until they can detect this successfully themselves, but then they would face pushback from consumers, who find the services of financial aggregators useful.

As I mentioned at the start, this topic is one of those that doesn’t have a clear-cut “bad guy” – apart from the criminals, of course! – and doesn’t have an obvious solution either. But, I felt it was an important topic worth covering, so companies that might be targets of this type of credential exploitation attack are at least aware of the problem and can control the conversation and next steps. I typically think it’s helpful to end a blog post with a “call to action”, and this one is no exception.

Here’s what I suggest you should consider if you are responsible for protecting a company whose data is accessed en masse by an aggregator. (Typically, you will be working at a financial services firm.)

1. Determine whether your policy allows the whitelisting of aggregators at all.
2. Review which aggregators have in fact been whitelisted*.
3. Find the contact information for said aggregators, and reach out to discuss what steps they are taking to detect the problem of criminal piggybacking on their platform.
4. Review your current anti-automation platform to determine whether it’s capable of detecting aggregator piggybacking.
5. Review the historical logs of transactions from aggregators to determine whether the login success/failure ratio has changed significantly over time. (Typically, failure rates on aggregator initiated transactions are very low. If failure rates suddenly spike, it is a strong  indication of piggybacking.)
6. If you are seeing indications of piggybacking, and your current anti-automation platform isn’t capable of solving it, please reach out to us and we can jointly determine how we can help.

* Whitelisting
In the context of this blog, when I use the term whitelisting, I am not referring to whitelisting on a firewall, or similar network security appliance at the TCP/IP address level. Although it’s possible that some TCP/IP addresses of aggregators may indeed be whitelisted at that level – otherwise at peak traffic periods, such aggregator initiated transactions might appear to be a DDoS attack, and get shunned by DDoS prevention solutions.

Rather, I am talking about whitelisting in two separate senses of the word:

1. Many financial services firms offer aggregators either JSON or XML-based APIs, instead of using simple site scraping technology.  Typically, these APIs have an authentication/authorization component, and so the process of allowing a particular aggregator to use those APIs is one form of “whitelisting”.
2.  Pretty much every firm will have some kind of fraud detection / prevention engine (whether home grown or a commercial product / service).  In that engine, the transactions that originate from aggregators will look unusual compared to the normal transactions that access your site. Depending on how your engine works, you will often need to “whitelist” those aggregator initiated transactions to ensure that they don’t trigger fraud workflows, CAPTCHAs, etc.  How that’s done will vary from one engine to another.

Interested in learning how you can protect your web mobile, and API, applications, and APIs from automated attacks and unwanted traffic? Get in touch, and we’ll demonstrate how we help some of today’s largest organizations in the retail and finance industries detect and mitigate bot activity.