How a Sneaker Bot Earned $2M Profit from One Shoe Drop

Continuing our deep dive into reseller bots, this article explores another real-world case of how a crime group using automated attacks profited from the purchase, and subsequent resale, of expensive and limited-stock sneakers. If you’re coming to this article fresh and would benefit from an extensive explainer on the reseller/shoe bot problem and the ecosystem which they operate in, check out our new Bots and Automated Attacks landing page.

Overview

The sneaker industry is one of the top sectors targeted by unauthorized resellers with their use of highly specialized automation tools known as ‘sneaker bots’. These bots are specifically designed to target large shoe drops (sales) for limited edition and rare sneakers. Working with the F5 security team that helps defend against bots and automation, F5 Labs has spent time analyzing huge amounts of attack data from one of the largest shoe drops in recent history. Since the F5 Bot Defense service was still in a passive ‘monitoring mode’ during the event, we were able to get an inside look into the operations of these bots and were able to track the activities of these resellers from start to finish without showing our hand. This allowed us to track the acquired inventory all the way to the secondary markets and to final consumers. This case study aims to share valuable insights into the operations of these shoe resellers and their sneaker bots.

Figure 1 shows mobile and web traffic for a large shoe manufacturer and retailer, here forth referred to as “the retailer”. The green line (barely visible as it is dwarfed by the high volume of automation) represents legitimate human users interacting with their website and mobile application. The yellow line shows the level of automated traffic from bots over the three-week observation period which represented more than 99.8% of total traffic to the retailer. Figure 1 shows that retailers are relentlessly targeted by sneaker bots and this malicious traffic increases drastically during periods when high demand shoe drops occur, as can be seen by the large spike in bot traffic which accounted for 2,163 times the level of human traffic. This automated bot traffic exceeded 8 million transactions per hour and is large enough to effect a denial of service (DoS) attack on the origin servers. As we detailed in Reseller Bots: Defining the Problem, automated attacks can cause many problems for manufacturers and retailers, including fraud, reputational damage, and denial of service (DoS). While some businesses struggle to comprehend the magnitude of threats such as reputational damage, a service outage caused by a DoS incident can be directly attributed to lost revenue.

Over the three-week observation period for this large retailer, 99.8% of traffic to their web and mobile applications was automated. Lucy Rouse, vice president and general manager of SNKRS and NBHD at Nike is recently quoted by retaildive.com saying “on any highly sought after sneaker launch Nike executes, up to 50% of purchase entries can be bots”. This is consistent with the data we have observed.

How Sneaker Bots Made $2M Profit From a Single Shoe Drop:

The automated traffic seen in Figure 1 is driven by a large number of individual sneaker bots. Some are small scale operated by lone individuals that want to acquire a pair or two for personal use, while some of the traffic originates from large scale resellers that attempt to buy hundreds of pairs for resale. To highlight the inner workings of these sneaker reseller bots, we are going to focus on the activity of a single large scale reseller sneaker bot. This sneaker bot followed a multi-step plan to enable them to make $2 million from this one shoe drop.

Figure 2 shows an overview of the kill chain used by the resellers and their sneaker bots in order to make huge amounts of profit.

Step 1: Fake Account Creation

Many retailers now require users to have a verified account in order to purchase shoes online. This means that guest checkout is no longer an option for both genuine customers and sneaker bots posing as genuine customers. Retailers have also imposed limits on the number of pairs of shoes an individual account can purchase, especially during high demand shoe drops. As a result, resellers who operate the sneaker bots are forced to create a large number of user accounts on the retailer’s system that they then use to make the purchases. They therefore need to coordinate and automate the process of creating the accounts. Figure 3 shows the account creation traffic of a reseller bot. This is traffic hitting the retailer’s sign-up/create-account pages.

Automated traffic originating from  1,400 different IPs, spanning 466 autonomous system numbers (ASNs), and using 125 different user-agent headers, shows the extent of the distributed infrastructure used by the sneaker bots in an attempt to avoid detection. This sneaker bot created over 2,600 fake accounts over a three-week period. Retailers suffering sneaker bot attacks will frequently see large numbers of fake accounts in their system. These can be identified through a number of methods including presence of incrementally generated usernames (for example, account_1, account_2, …account_n) and presence of large numbers of accounts sharing the same password.  The attackers tend to try and reduce operational overhead of running their bots and managing their accounts. This allows them to easily loop through the accounts at high speed without needing to lookup usernames and passwords from a file. This additional time saved gives their sneaker bots an advantage over other bots also competing for the same inventory.

This particular sneaker bot was creating accounts steadily over time to reduce the chance of them getting detected and the accounts being suspended. Accounts are created in advance of the shoe drop and resellers will populate the account profiles with details such as payment cards and delivery addresses that will be used to checkout. This saves valuable seconds in the checkout process by not having to complete these details during the heat of the shoe drop. How far in advance of the shoe drop the accounts are created depends on the requirements of the retailer. Some retailers require a long-term account or purchase history in order to get access to limited shoe drops. For these retailers, bots are forced to create the accounts far ahead of time. If no such requirement exists, then accounts can be created just a short time before the shoe drop begins. Once created, the accounts will be logged into before the sale begins in order to obtain session cookies for each of their accounts, so as to optimize the process once the shoe drop begins. This is because the process of logging in wastes valuable time and could result in a sneaker bot losing out to other faster sneaker bots. Hence every effort is taken to optimize every single aspect of the process to ensure the best results and profits.

Step 2: Reduce Wasted Time

The most important step in the sneaker bot’s operations is adding the desired inventory to the cart. Most retailers will temporarily withhold inventory once it has been added to cart. This means that once added to a cart, a particular pair of shoes is taken out of inventory temporarily to prevent the same pair being bought by two different customers. It is the sneaker bot’s objective to add as many pairs of shoes to carts as fast as possible. Therefore, the speed with which this can be done is of the utmost importance. In order to maximize their chance of success, resellers using sneaker bots must consider a number of aspects:

1. The importance of getting in early and knowing when the shoe drops are happening
2. Identifying the target product web page
3. Adding desired items to cart as quickly and successfully as possible

The Importance of Getting in Early

The exact start time for shoe drops is usually publicized well in advance of the sale. However, products may be released a few minutes earlier than the advertised times. Resellers therefore start checking the site for the desired product up to thirty minutes before the official shoe drop time and will continue to check at very short intervals to ensure that they are the first to know as soon as the products are available to add to cart.

Identifying the Target Product Web Page

Humans shopping on a retail website typically have to navigate from webpage to webpage. That is to say, they start by typing in the address of the retailer’s homepage and wait for it to load. Then, they may see a banner image advertising the sale. The user clicks on it, waits for another page to load, only to see a list of all sale items. The shopper then needs to search for or browse for the specific item they want before waiting, again, for that item’s web page to load. All of this searching and page loading wastes valuable time for resellers and they have become very good at predicting or discovering the product URL before the launch. This can be done by either viewing marketing material for the sale which often includes the exact web page address (URL), or by examining URL naming conventions for that retailer and guessing at the correct address.

Knowing the correct URL for the item they are targeting allows the sneaker bots to preconfigure their bots to target that URL directly and add that product to the cart directly without ever navigating to, loading or viewing the product page, saving valuable time.

The HTTP “referrer” header, used to indicate the previous web page the client was on, is often useful when examining legitimate and malicious web traffic. In this case, the referrer shows the URL of the webpage the shopper was on when they added an item to their cart. This is typically the address of the product web page when the visitor added it to their cart. In this instance all “add to cart” transactions for this sneaker bot had no referrers. This shows that the “add to cart” request was created on the fly by the bot and was not created from the product page, as would be the case for genuine users. This means that the bot knew ahead of time what product details to add to cart without navigating to the product page first.

Add Items to Cart as Quickly as Possible

As described above, the reseller’s sneaker bots do not navigate the site but, instead, initiate a single transaction, typically an HTTP POST, directly to the “Add to Cart” endpoint. Resellers decide in advance the number, color, and size distribution of the desired inventory. This allows them to configure and hard code these details into the request sent to the “Add to Cart” endpoint. Determining the size, color, and quantity of shoes they will purchase in advance allows the resellers to take pre-orders and program the sneaker bots ahead of time to get the correct specifications of desired shoes.

Figure 4 shows an example of the add-to-cart HTTP transaction to add a specified shoe to the sneaker bot’s cart. The URL contains all the details about the shoe being added to cart including product ID (pid), size, color, style, width and quantity. The sneaker bot is able to create valid add to cart requests for all the required shoes without ever loading the product webpage.

Figure 5 shows the sneaker bot’s traffic targeting the “add to cart” endpoint. In pursuit of inventory from a single shoe drop, this reseller bots attempted 44 million transactions in the space of a few hours. However, due to stiff competition from other bots only a small percentage of these requests were successful in adding inventory to the cart

The bot once again used a widely distributed infrastructure of over 25,000 unique IP addresses from 321 different ASNs that were a combination of US hosting and residential providers. Using North American ASNs prevents the bots being geo-blocked by the retailers who typically may block traffic originating from outside the US. Using residential ASNs also mitigates the risk that the retailer may block the use of cloud hosting ASNs which are typically cheaper and preferred by bots.

Step 3: Change Shipping Address and Save Costs

As explained in the Reseller Bots: Understanding the Ecosystem, resellers can have the inventory (shoes purchased by their sneaker bots) shipped to a variety of place including, but not limited to:

1. The reseller’s location
2. A reshipper
3. A secondary marketplace like Amazon or StockX
4. A third-party buyer’s location

The choice will depend on the reseller’s business model, as well as the limitations imposed by the retailer. Some retailers will check to ensure that large quantities of shoes are not being shipped to the same address.

Resellers that take pre-orders often attempt to optimize their profits by completing the transaction with the name and shipping details of the final consumer, thereby removing the reseller’s shipping costs by having the retailer ship the product directly to the end consumer, saving both time and money.

As can be seen in Figure 6, this sneaker bot hit the shipping address page 41,000 times. Due to privacy requirements preventing the logging of shipping addressees, we have no visibility into delivery locations used by the sneaker bot. Whilst the activity logs do not show shipping addresses, this is something that the retailer can readily see during the check-out phase and configure security controls to mitigate the risk. Although security controls based on the shipping address may provide some temporary relief against these kinds of attacks, it poses only a modest hurdle for the resellers. Those resellers who are sufficiently motivated will acquire many varied addresses to use to circumvent such controls.

In this case study, the sneaker bot sent 44 million automated “add to –cart" requests. Of these automated transactions, only 41,000 updated shipping information. The address changes were very likely due to the sneaker bot submitting the delivery address of the third-party buyer that had placed pre-orders. For the vast majority that did not change the address, this was due to default shipping addresses being used. There is also a large proportion of the “add to cart” transactions that were not successful in adding shoes to their carts. These transactions would also never get to the shipping step.

Step 4: Reduce Costs by Using Stolen Payment Cards

The last step the reseller bot has to perform on the retailer's site is to checkout, pay and finalize the purchases. This is a complex process that is explained in detail in Reseller Bots: Understanding the Ecosystem.

As seen in Figure 7, the same sneaker bot can be seen checking around 278,000 times. This is likely due to the use of stolen payment cards resulting in failed bank authorizations during the payment process. In this scenario, the sneaker bot will attempt multiple stolen payment cards until one works. This is a process called “carding”, and results in large numbers of card payment attempts relative to the number of actual orders.

Figure 7 also shows once again the continued use of a widely distributed infrastructure of IP addresses and ASNs.

Step 5: Now For Profit

Once the reseller bots had successfully acquired the required inventory, they listed and sold the shoes on secondary marketplaces such as StockX and eBay. During our investigation of this incident, we were able to find the listings for the shoes soon after the shoe drop. Figure 8 shows our estimation of the business economics for the resellers.

Given the volume of transaction from this sneaker bot, we were able to estimate that the reseller made between $1.1 million and $2 million profit from this one shoe drop. This is assuming they were able to acquire 10,000 pairs of shoes and sell all of them on the secondary market. The estimate of 10,000 pairs is, however, quite conservative given the 41,000 shipping address changes and 278,000 checkout transactions. This shows that while the profit justified the time, effort, and expense incurred by the reseller, they required $1.7 million investment to acquire the initial inventory. How much of this $1.7 million was funded by stolen payment cards, however, is unclear. Clearly, the business of sneaker resellers requires large professional operations that are well funded and motivated and they will invest in the resources needed to circumvent any controls put in their way.

Conclusion

This article gives a case study of a real-life reseller sneaker bot campaign against a large shoe retailer’s site and gives step by step walk through of the steps taken by the reseller from start to finish. It covers the various considerations and steps taken by the resellers to optimize efficiency and profitability, while bypassing existing controls and beating other sneaker bots. It ends off by giving some insight into the economics of this business operation by looking at the monetization steps taken by the reseller. These reseller bots are professionally run and well-funded enterprises that are determined to stay in business. This is why sneaker bots and resellers are such a difficult problem for OEMs and the security community at large. There is immense value for all the ecosystem players who will rally together to ensure the continuation of the enterprise.

Recommendations

Our breakdown of security controls to limit the effectiveness of reseller bots can be seen in Reseller Bots: Defining the Problem.