Attack Tool on the Rise: Account Checker

F5

Today we introduce and explain an attack tool that is becoming more prevalent among our customers: the Account Checker.

This credential stuffing tool isn’t new, but usage is rising sharply for reasons we’ll discuss below. Although very conceptually simple and easy-to-use, account checkers are extremely powerful.

Description of Account Checkers

An account checker is an attack tool that takes lists of spilled username/password pairs (i.e. “credentials”) and tests them against a target website.

Powerful account checker packages cost as little as $100, and adversaries can also create their own account checkers from off-the-shelf web automation toolkits like Mechanize, PhantomJS, IEC.py, Sikuli, Selenium or iMacros. These toolkits reduce the technical burden to write account checkers and conduct credential stuffing attacks.

Anatomy of Account Checker Usage

1. Attacker acquires spilled passwords from a website breach or from password dump site
2. Attacker uses account checker to test stolen credentials at many websites
3. Successful logins (usually 0.1-2% of total) result in account takeover
4. Attacker drains stolen accounts of stored value, credit card numbers, and other PII
5. Attacker may also use this account for other nefarious purposes (spam, further transactions, etc)

Example of Benign Account Checker

Below is a ‘benign’ account checker called namechk.com that illustrates how account checkers work. This tool checks if a given username is available on various social networks. We checked the username “shapesecurity” and this tool correctly identified all the sites on which that username was taken.

This service uses a script that automatically tests a given username against all the websites visible in the image (e.g. Blogger, Facebook, Youtube, Twitter, etc.).

A criminal account checker functions in the same fashion as the above tool, and adds additional capabilities like checking whether various passwords (based on guessing algorithms, or one of the top 25 passwords) work on that site. The full process of checking usernames and passwords, along with malicious intent, leads to the widespread attack of credential stuffing.

A Microsoft study found that the average user has just over six passwords, that each password is shared across four different sites, and that each user has about 25 accounts that require passwords. Meaning breach anywhere results in passwords on 3.9 top sites becoming public.

Example of an Attack-Ready Account Checker

Brian Krebs wrote about the off-the-shelf account checker below. This is the same type of tool used to hack Hilton.

This checker is able to ascertain whether credentials are valid, and scrape the point balance, last four digits of the credit card number, and billing address of the card.

Below is a sample of the underlying code of an account checker. This account checker tests large numbers of credentials. When it finds a valid pair of credentials, it scrapes PII and steals stored value and credit card details from the account.

Where do attackers get lists of credentials?

The fuel for any account checker is a list of credentials. Fortunately for attackers, there are a huge number of credentials that are public.

• 38,000,000 Adobe accounts
• 318,000 Facebook accounts
• 70,000 Google accounts
• 60,000 Yahoo accounts
• 22,000 Twitter accounts
• 8,000 ADP accounts
• 8,000 LinkedIn accounts

Hundreds more credentials are leaked each day on this twitter handle: twitter.com/dumpmon. Many security professionals use this list to identify which user accounts on their respective sites have been compromised, and to lock out compromised accounts. Obviously, attackers also use this list, in conjunction with account checkers, to find vulnerable accounts which they then use for various fraudulent activities.

What can security professionals do to curb account checkers and prevent attackers from hijacking user accounts?

The answer requires an understanding of the mechanism by which account checkers work.

Account checkers work by using the static form elements of the login page as an implicit API. In the code sample above, the attacker references various form element names in order to interact with the target webpage. Most websites cannot distinguish such interactions from normal human interactions

and thus gladly accept the attacking traffic. This allows the attacker to automate the website using account checkers and easily run through millions of tests over the course of a few days or weeks (often using a large distributed botnet and a huge number of IP addresses in order to avoid rate and volume limits). Thus, even very unsophisticated attackers can trivially launch potent attacks against many of the largest websites in the world.

To defend websites against such activity, which we call “unwanted automation”, we use an approach that is familiar to attackers – we change the underlying code of the site on every pageview. Just as malware authors have long used polymorphic code to evade antivirus products by constantly presenting different signatures, so Shape’s solution creates a moving target which frustrates scripts that seek to automate a website. This allows sysadmins to increase the effort an attacker must invest to successfully script or automate a given website.

Of course, savvy readers will point out numerous ways in which to conduct attacks in different ways. It is beyond the scope of this article (but perhaps the subject of future pieces) to consider such attacks (DOM, GUI, and other). Shape of course is keenly focused on comprehensively defeating all such attacks and has solutions at each of those levels.

About the Author

F5

More blogs by F5