Protecting your PaaS E-Commerce Site Against Account Take Over (ATO)

Account take over (ATO) is a problem for every organization that has an online portal. If you are reading this, have an online portal, and think that you don’t have an ATO problem, I would challenge you to take some time after you finish reading and hunt for ATO in your environment; I can almost guarantee you it’s there. That said, ATO is an especially challenging problem for organizations which protect sensitive personally identifiable information (PII) and even more so when the site manages financial transactions. However, private information of any kind will fetch money on illicit, underground forums; this makes virtually everyone a target. Working as an incident responder, I deal with this type of activity on a weekly and sometimes daily basis. These experiences have taught me a lot about how these attacks are launched and where they tend to be focused. One factor that makes dealing with this activity difficult, is the fact that my company develops against a PaaS solution and employs the use of many third-party APIs. Such implementations are inherently complex and such complexity often works in favor of the attacker. All is not lost however and it is possible to protect your site. Below are a few steps our company has taken to ensure we are covering our bases.

Monitor and protect your API endpoints
ATO often begins at your identity API. For a lot of companies, this is a purchased service that they integrate with. Using a third-party for this can make monitoring your endpoints more difficult. Depending on who your identity provider is, this may mean that you have a JavaScript widget which is embedded on your login page, that makes the call to the identity API. In other cases, this call may proxy through other services such as an analytics engine, a PaaS load-balancer, or some other technology. The extra layers of technology can make it difficult when you are trying to gather logs, especially in an incident response situation. Either way, the request must eventually be forwarded to your identity provider. To ensure that you have visibility at every layer of the transaction, be sure to pass an X-Forwarded-For header with each request and make sure that header is properly parsed as it moves along the stack. Nothing is more frustrating than having the data at your fingertips, but not being able to retrieve it because it is not being parsed. Of course, life is much easier when your identity provider has a SIEM connector, but this may not be the case with some providers. Such was the case on our site and we had to work directly with our identity provider to develop this capability. A cumbersome, but worthy effort. Additionally you will want to log the user-agent string, request body, method, and response if possible. While it is trivial for an attacker to jitter many of these, it makes detection much easier if you have this data logged and available to an analyst.

Have a rate-limiting policy that makes sense
It is a simple rule, but encountering a rate-limiting policy of any kind can significantly decrease an attacker’s productivity. If you limit login attempts to even 10 requests per minute you become a much less attractive target to an attacker. This has to make sense for your site. Also, don’t just focus on your login portal for this. Fraudsters will often validate cards in an account portal by simply iterating through card number / CVV combinations. Changing a card number / CVV combination will usually kick-off a $0 authorization to validate the card. If these portals are not rate-limited, this can become a free carding tool for an attacker. The same goes for gift-card balances (for gift card fraud, I would highly recommend reading the research put out by Will Kaput.)

Enforce geo-ip restrictions
This one is a bit more of a battle, especially when interfacing with Customer Experience teams or other folks in the business. Essentially it boils down to this simple rule: if your company does not have legitimate business interests in a particular Country or region, block it. Plain and simple. Some folks on the business side will push back citing things like “some customers may travel”. This is a legitimate concern for the business and a discussion will have to take place. However, in the end, you may find that it serves you best to restrict logins and transactions to only those geographic areas that you service. Having this protection implemented can protect you from international botnets and other threats abroad.

Trigger a CC revalidation when account changes are made
If you process credit card transactions and ship product, you should always prompt the end-user to re-validate their payment information when making a change to their account such as shipping address or e-mail. Such controls prevent threat actors from successfully carrying out triangulation fraud scams. Triangulation fraud occurs when a threat actor advertises a product for sale, receives a purchase, and then uses a compromised account or other illicit means to fulfill the order. In my experience, this is the end goal for a lot ATO related activity. For more information on how these scams work, I recommend taking a look at this post by Brian Krebs .

Image: Krebs on Security

Have a clearly defined response workflow, specific to ATO
This seems like a no-brainer, but large, coordinated ATO attacks can sometimes catch the business by surprise. While you will want to have a plan for the sake of rapid response and mitigation, the company will often have a responsibility to disclose ATO activity to their customers, since PII can be exposed just by logging into a person’s account. Doing so sooner rather than later is always in the best interest of the organization. However, you also want to have a high-level of confidence that the accounts of those customers you are notifying has been secured. Thus, having a plan will greatly reduce the response time end-to-end, placing the business in a better position for customer notification. These workflows are often quite repetitive and can be expedited by building out a tool for automating the process. I am currently involved in such a project and hope to release the code later this year.

Purchase an ATO protection suite for your portal
There are a number of options in this space, but Kount Access seems to get fantastic reviews. The cost is quite low compared to the potential loss and the metrics it provides are fantastic. The biggest obstacle here is usually getting development resources allocated to integrate the protection. However, the return on investment is definitely worth it.

I’m sure as you were reading through this post you were thinking, “I could circumvent $x control this way,” and “$y control is easily bypassed by doing $z” (I should hope you were thinking that way; you’re a security practitioner after all!). It is true that each of these controls can be defeated by a determined attacker. However, with each control you implement, you add an extra layer of difficulty that the attacker must circumvent to be successful. The goal here is to make ATO difficult enough for the attacker that their profitability is destroyed and they move on.

These are the basics, but there are a number of other things you can do to better protect your site as well. One such idea is to integrate your login portal with the Pwned Passwords API, offered by Troy Hunt. This can be implemented in a way that maintains k-anonymity and protects your customers’ passwords, while forcing users to select a password that has not appeared in a breach dump. Get creative! I have tried to begin analyzing attacks like this holistically and engaging partners beyond just my infosec peers. Doing so has led to collaborations within our business that we never had a year ago. In some cases, it has even led to law enforcement kicking in the doors of some of these attackers and shutting down their fraud ring. If you have any questions, please feel free to reach out to me at



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s