First victims of the rise of VPN credentials stuffing attacks

Preface

We hope that information shared in this article may be useful for VPN service providers and online services. We have tried to fill it with as many details as possible to provide a better view on this issue. If you have been a target of the same type of attack and need advice – do not hesitate to contact us. We will be happy to share our knowledge.

Intro

Le VPN was a target of DDoS attacks for a countless number of times in the past, but a couple of weeks ago we have noticed something different and new to us.

Another botnet, which usually targets our client management system, has now changed its attack direction to our API. A quick glimpse at this showed that it was a credentials stuffing. Someone was using a collection of previously stolen credentials to try to check them against our user base.

Le VPN is mostly immune to this attack vector as we generate a unique username for every new user.

An exception is a fraction of our users that migrated to Le VPN from another VPN provider without such a policy in place.

This highlights the importance of using different passwords both as an individual accessing multiple web places and services and for companies to deploy password security policies.

Reflecting the attack

Requests made by this botnet were easily identifiable, so we have split them from real API requests. Instead of passing through API algorithms, malicious requests received a standard error message and saved in logs for future analysis.

We thoroughly checked that none of our clients were impacted and that the attack represents no danger to our system.

With this in mind, we have decided to leave it running for a couple of days to gather more data.

Attack persisted at the same pace for a few days and it was now time to proceed with the investigation.

We would like to present to you our findings below.

Botnet

The botnet used for this attack was relatively small – about 40 000 – 45 000 bots in total. The number of simultaneously active bots was even smaller – usually less than 10 000.

According to our records, the same botnet was utilized throughout the whole duration of an attack.

Origins of bots’ IPs were mostly Chinese (75%), Indonesian (4%), Thai (4%), and Brazilian (4%), with smaller fractions from other countries. The majority of Chinese bots had IPs from Chinanet and China Unicom.

Attack pace

At some point, we have decided to measure botnet’s full attack pace. We have stopped all related rate limiting and traffic filtering rules and started to absorb all botnet’s requests.

During that, botnet performed at the pace of around 3 requests per bot per hour. It has not differed much from the usual rate with all defenses turned on.

That made us believe that the attack pace was lowered intentionally, in order to not trigger rate-limiting rules which may resolve in botnet IPs permanent ban. That being said we believe that this pace may change depending on the target’s defenses.

Based on this estimation an attacker with similar botnet size can perform roughly around 500 000 credentials checks per day.

Requests per credential

Another observation that we found interesting is the number of requests per credential. The majority of username/password pairs were sent only once with some small portion of them being sent twice. This may indicate that attempts are centrally managed and probably synchronized.

The source of stolen credentials

Another aspect of the investigation was to identify the source of these leaked credentials. We have selected a representative sample of credentials used in this attack and carefully looked them up. Almost all of them are present in the “Collection” (https://en.wikipedia.org/wiki/Collection_No._1) which made us believe that this was the main source of this data.

However, our rough estimation is that an attack uses around 10-15 million credentials, not the whole “Collection”.

We estimate the total time needed to complete this attack with the aforementioned pace and dictionary size to be around 20-30 days.

Who is behind all that?

We wanted to go a step further and gather more data about the attacker. Therefore, we have set up our API to randomly reply to malicious requests with a success status code. This approach generated a list of false credentials, which cyber criminals may attempt to distribute or to authenticate against our AAA servers.

The objective was to see where this list pops up and connect the dots. As soon as it was done, we have started to monitor the web.

Unexpected results

The results were quick and unexpected.

We have found more than 1000 VPN credentials supposedly related to one of the big VPN providers. Some of them were published at the end of April and others in the beginning of May 2020. All of these leaked credentials were publicly distributed for free in an online community related to Iran.

We immediately submitted our findings to that VPN provider’s bug bounty program and requested their tech support to notify the cybersecurity team about this incident as soon as possible. We are still waiting for their reaction.

Same attack?

After notifying the provider we moved on with the analysis of leaked data.

We checked the exposed credentials and were surprised to find that most of them were present in the aforementioned “Collection”, the same source of leaked credentials an attacker used against our API.

There were some records present in other lists of breached credentials; however, every credential we tested was inside one set of breached data or another.

Moreover, one of the lists of exposed VPN credentials contained an expiration date and time with exact minutes and seconds, which looks similar to an API response.

We cannot enumerate the total number of compromised credentials as new lists continue to pop up every few days.

How it all ended (for now)

We take security seriously at Le VPN and during every attack, thus we prepare for the worst.

The botnet that hit us was relatively small so we have tried to simulate our response for a scenario with a much bigger botnet.

It involved dropping any connection with the botnet as soon as we identify it. In this scenario, the attacker does not receive any response from our API so the load on our API servers is minimized.

Shortly after we have started to test this solution in production, an attacker decided to stop further credentials stuffing attack and launched a final, short, and unsuccessful DDoS on our frontend. Attacks have not reoccurred since then.

Final thoughts

There are still lots of questions that remain to be answered.

Even though the origin of botnet itself is highly likely to be in China, the group or individual who rented it may be located somewhere in the Middle East.

We are not sure if the same actor attacks multiple VPN services or if this is the new trend adopted by different groups.

We think that hijacked accounts may be distributed in countries such as Iran, where censorship levels are high and VPN services are mostly not available due to international restrictions.

The easiest target for this type of attack will be VPN services with the biggest user-bases as the number of active clients increases the probability to find leaked credentials. Moreover, it is easier to hide botnet activity behind a bigger number of API requests.

We are still waiting for the action to be taken from the VPN service whose accounts were exposed. If it will not be done shortly, we will try to notify related users ourselves.

We will update this article if we have new details on this issue.