Credential Stuffing: How breached credentials are put to bad use.
At Breach Insider, we see a similar story over and over again via social media and other outlets, with folks suggesting various companies may have suffered a breach due to their accounts becoming compromised, or receiving spam:
While there is the possibility that this may be the first sign of a breach, there are some other reasons why this may have happened:
- The person has reused credentials from another website which has suffered a breach, and these are now being used by malicious folk against other services.
- A third party to the company in question has suffered a breach, meaning only partial details have gone public e.g. A third party marketing company with names and email addresses.
- It is a very targeted attack against the user in question, and someone has managed to successfully guess or bruteforce the users login details.
What is Credential Stuffing?
With quite literally billions of leaked credentials available online, it is highly likely that some of these will be credentials for your customers — or worse — from your employees or organisation. These details can then be used by nefarious people to then systematically attempt to log into your service/business, in an attempt to takeover these accounts. This article will provide you with an overview of why and how these attacks take place, as well as provide you with some fingerprints and identifiers to help you monitor your environment for these types of attacks.
So, at this point, you might be thinking:
My website doesn’t hold any important information, so I doubt we would be a target…
Depending on your business, you may be more attractive to this attack than others. It all depends how valuable your users are and how the contents of the account may be used or sold on to others.
Lets walk through some examples, and explain why they might be an interesting target for some nefarious people:
Example 1 — The E–Commerce Store
You are an online shop, hopefully selling something people want to buy. Chances are, you ask people to register as they make purchases so that you can store some of their information (address, payment details) to enhance their user experience when they return.
Depending on your scale or target market, you may also be attempting to retain those customers with loyalty schemes, such as a points based system based on previous purchases.
There are a number of reasons why someone may target your business:
- Make orders using someones stored payment details
- Make orders using stolen or purchased credit card details from underground/black markets
- Obtain further details (home address etc.) of a customer to allow for a more convincing ‘phish’ to be created.
- Identify accounts with a large quantity of loyalty points, to make a purchase when payment details aren’t available.
Example 2 — The Popular Service
You’re a popular service that people likely subscribe to at a cost (e.g. Netflix), or a free service where the users can gain something over time (e.g. HackerNews).
There are a number of reasons why someone may target your business:
- Use a compromised account for their own benefit, allowing them to use it for free
- Resell compromised accounts to others at a “discount” compared to your original price
- Abuse a known & trusted account within a community to spread information (malware, spam etc.)
Example 3 — The Games Website
You’re a gaming website, where users can register and either play/complete via a web browser (e.g. Habbo Hotel) or you allow people to purchase games via your online store (e.g. Steam).
Reasoning here will be similar to an e–commerce website if transactions can be made. There is also the likelihood that as players spend more time on your service, they will gain items or experience. These accounts can be considered valuable in a similar sense to loyalty points, and so they can be sold or traded to others looking to gain access to a longstanding account with valuable resources or experience level.
Example 4 — The Points Website
Some websites are specific to allowing users to accumulate points, such as frequent flyer points (Avios) or loyalty purchase points (Nectar). Alternatively, your website may reward the user with points/money as they complete a number of tasks, such as cashback websites or rewards for completing surveys.
As above in our earlier examples, these websites will likely be targeted for the following reasons:
- Compromise accounts with a large number of points to easily exchange these to physical money or items.
- Compromise multiple accounts to transfer loyalty points to another user, to harvest a large number of points.
Some popular targets for credential stuffing include:
- Netflix (Accounts sell for $1–$10)
- Avios ($5–$100 depending on number of points)
- Groupon ($8–$10)
- PizzaHut ($2–$4)
- Nectar ($2–$25 depending on amount earned by account)
- Deliveroo ($5)
What we can see here, are those compromised accounts aren’t being directly used by the person who has completed the ‘credential stuffing’, but instead advertised and sold on various marketplaces to willing purchasers.
Tools and Techniques
So we know why we might be a target, but what are they actually doing, to be able to use ‘credential stuffing’ attacks against my website?
OWASP provide a pretty good overview of credential stuffing, essentially it is the automated usage of previously dumped or breached credentials, against another website or service in an attempt to maliciously gain access to another persons account. Here is what that looks like as a flow:
- A list or dump of
username:passwordcombinations are obtained
- The obtainer may or may not cleanse this data, depending on their level of ability & confidence in the source.
- They could then start attempting these credentials against the target website, however that isn’t very efficient. Luckily for them, there are a number of tools at their disposal:
- Sentry MBA
- Account Hitman
- There are also some site specific tools, such a for Netflix, Amazon, & Origin
- With their tool of choice, it is now time to either create a configuration file for their specific target, or go and download/purchase one that has already been produced. A quick search for ‘Sentry MBA config’ reveals just how popular the tool is.
- Optionally, they may import a list of open proxies to pass the data through, obscuring their true IP address or approximate location.
- They import their credentials in the required format, and can then alter some of the configuration variables before launching their attack. Variable include:
- Random User–Agent string
- Random proxy and how often to jump between them
- HTTP request header format
- Once the attack has started, a live update is provided to the attacker, with HTTP response code statistics (2xx, 3xx, 4xx, 5xx responses). They are also give a list of successfully accessed accounts, with any additionally scraped details if this was configured as part of the script e.g. level of points, account status etc.
Now we know roughly what the attack looks like, lets take a closer look at the tools used and some of the ways we can identify them to help protect your legitimate customers.
Sentry MBA is the tool of choice for our nefarious friends, with the vast majority of publicly available configuration files being created specifically for Sentry MBA.
Version 1.4.1 is widely regarded as the latest edition of the tool, however there are copies of the executable available touting to be versions 1.4.2 or 1.5.0. Due to the nature of these types of tools, it is unclear who the original creator was, and whether these updates are genuine. It is highly likely that they have been maliciously modified to spread malware or to steal other peoples credentials/information.
Sentry MBA configuration files can be found on a number of public forums, PasteBin style websites, as well as being created and shared between users of the tool. The configuration files following a common pattern what can be parsed by the tool:
[Settings] #Section containing generic settings, such as SiteURL, #HTTP Header format & POST data. [Fake] #Section for how the bot/script should behave, such as following redirects, #how often to rotate proxies, connection timeouts etc. [Keywords] #Key strings or text to identify if the bot has successfully accessed an #account, if it has failed, or if it has been banned. [Form] #The form details, such as fields, POST address, any cookies #which should be set, AJAX settings. [Ajax] #Further AJAX configuration if needed, such as variables, redirection URL etc. [OCR] #Enable or disable OCR, and settings to identify the images, complexity etc.
Depending on your target, you can also configure the ability to scrape a section of the site if the authentication was successful. This allows the user to identify key account attributes, such as targeting account billing information, level of access or experience, or for sites like Avios - level of points.
Sentry MBA also contains a list of default User–Agent strings which persist across configuration files. Whilst these defaults can be easily changed, it appears to be common practice (or lack of understanding) to change them to blend in with genuine traffic.
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2009060215 Firefox/3.0.11 Mozilla/5.0 (Windows; U; Windows NT 5.1; en) AppleWebKit/522.11.3 (KHTML, like Gecko) Version/3.0 Safari/522.11.3 Opera/9.80 (Windows NT 6.0; U; en) Presto/2.2.0 Version/10.00
If a configuration file isn’t for Sentry MBA, then chances are it will have been written for Account Hitman. This tool appears to be a 2nd choice for many users, likely depending on how readily available the relevant config file is that they are looking for.
Two versions are widely available — 0.98 & 1.33. The former appears to be the last genuine copy, with 1.33 having tweaks applied at a later date by someone other than the original creator.
The configuration files for Account Hitman are XML based, making them less user-friendly to alter outside of the tool, however they cover similar properties to those mentioned for Sentry MBA, such as
HTTP Headers and
POST data. There are also sections to help the tool identify successful logins, failed authentications, and banned proxies.
Because these config files have likely been created by a user within the tool, there are areas where specific settings are re-used across all of the requests (and subsequently across multiple attacks as the config file is shared and goes unaltered). For example, one configuration file contained the following HTTP header settings:
[Method] HTTP/1.1 Host: [URLBase] User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv8.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3 Referer: [Referer] [ContentTypeBool] [ContentLengthBool] Connection: Close Cookie: uid=<<vCookie>>; lang=en; domain=com; __cfduid=decef6d8ebed64280bfff8daae3b304861430035186; [ProxyBool] [PostData]
Therefore, every request within this attack will have the same
User‑Agent, making a very specific combination to fingerprint these connections. More on this later.
Once again, similar to Sentry MBA, there are a number of default User-Agent strings available to the user, some of where should stand-out if they are ever used in an attack:
Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; Media Center PC 4.0; SLCC1; .NET CLR 3.0.04320) Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US) Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; InfoPath.2) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Mozilla/4.0 (compatible; MSIE 5.00; Windows 98) NSPlayer/188.8.131.5280 RMA/1.0 (compatible; RealMedia) WinampMPEG/5.0 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20080404 Firefox/220.127.116.11 ia_archiver ia_archiver-web.archive.org Mozilla/2.0 (compatible; Ask Jeeves/Teoma; +http://sp.ask.com/docs/about/tech_crawling.html) Googlebot/2.1 (+http://www.google.com/bot.html) Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Mediapartners-Google/2.1 msnbot/1.0 (+http://search.msn.com/msnbot.htm) Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp) Mozilla/4.0 compatible ZyBorg/1.0 (firstname.lastname@example.org; http://www.WISEnutbot.com
Vertex is the third tool of choice, with a rather limited following possibly due to its age - the current version is 1.0.4 and was released 10th January 2016, with 1.0.3 becoming public on 6th November 2013. Config files are still being actively created, according to various message–boards and forums.
Config files for Vertex are formatted similarly to Sentry MBA, with a primary section for connection settings (User-Agent, Invalid/Success/Banned strings, POST data, HTTP Headers etc.), and subsequent sections for parsing/scraping sections of the page (days left, plan summary, downloads left etc.).
Interestingly, the full HTTP headers cannot be configured meaning Vertex connections will be easier to fingerprint compared to some of the other tools, even if the user changes or updates their configuration file. The default User-Agent string, when one is not set by the user, is as follows:
Mozilla/5.0 (Windows NT 6.1; rv: 17.0) Gecko/20100101 Firefox/17.0
A number of options are available to us to help detect the tools outlined above, however implementing them will depend heavily on your environment and your infrastructure.
Below, Breach Insider will outline a number of generic ways to identify these attacks, and will then look at specific ways to fingerprint each of the tools.
Generic Attack Identification
A key indicator that you are suffering an account takeover/credential stuffing attack, is you will see a sharp rise in the number of authentication attempts against you platform. Please note: The people performing these attacks and compiling the config files will not limit themselves to your standard login form/page, and will use alternatives such as API endpoints, support forums etc.
- Default User-Agent strings are commonly used during attacks, likely caused by the user being unaware of how outdated they are, or simply being unaware that they can be changed within the tools. Each section outlining the tools above provides a list of the default User-Agent strings.
Sentry MBA company(or another of the tools), where company is your business or product name, looking for configuration files or chatter on clear web forums requesting a config file. If you discover a configuration file & are able to source a copy of it, you may be able to identify further attacks where the default User-Agents have not been utilised.
- Often the tools contain a debug mode, to assist when you are starting out with a new target or config file. The default User Agent for this mode is again outdated and a potential indicator:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)
Mozilla/5.0 (Windows NT 6.1; rv: 17.0) Gecko/20100101 Firefox/17.0
Use the configuration file written specifically for your website, to identify key attributes and fingerprints which can be found within your web server log files:
- Hardcoded User Agent string
- Hardcoded ‘Referer’ header string
- Depending on your level of logging, hardcoded cookies & values
- Hardcoded redirections which are uncommon among your genuine users e.g. Login and instantly navigate to billing, rather than your standard dashboard.
Depending on your setup or environment, you may be able to identify this activity from the order of the Request Headers received. For example, if you have a packet capture or IDS installed which records the request headers, check for abnormal requests or requests which match the configuration file for your website.
Some default HTTP headers exist for each of the tools, which may provide an indication if you have suffered an attack. Please note, the defaults may have been changed within the config file.
<ACTION> <FORM ACTION> <HTTP VERSION> Accept: */* User-Agent: <USER AGENT> Host: <HOST> Pragma: no-cache Connection: keep-alive
[Method] [URL] HTTP/1.1 Accept: */* Accept-Language: en-us Referer: [Referer] User-Agent: [UserAgent] [ContentTypeBool] Host: [URLBase] [ContentLengthBool] Connection: Close [CookieBool] [ProxyBool] [PostData]
[Method] [URL] HTTP/1.1 Host: [HostURL] User-Agent: [UserAgent] Accept: */* Accept-Language: en-US,n;q=0.5 Connection: Close