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.
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.
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.
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.
The fuel for any account checker is a list of credentials. Fortunately for attackers, there are a huge number of credentials that are public.
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.
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.