When our customers engage the CQ Prime Threat Research Team for help, it is typically driven by some sort of compelling event. It may have been a potential compliance issue from an exposed API, an aggressive Account Take Over or Shopping Bot attack.
In all of these cases our process is the same. We get integrated into the application infrastructure and begin the work of finding Indicators of Compromise (IoCs). This involves looking at obvious endpoints like /api/v1/login for interesting activity. Another obvious target would be /api/v1/order where we find interaction between users, IP addresses and order numbers. But how do we know what to look for and is what should you are looking for the same for APIs and web apps?
Low Hanging Fruit
Some things line up nicely in order for one to figure out where to look and what to look for. In Account Take Over, for instance, we are primarily looking at the login application flow with a singular focus on Usernames, Passwords, IP addresses and User Agents along with how the attack might be performed. These data points line up nicely with our four pillars of detection – Credentials, Tools, Infrastructure and Behavior- and can help you identify where the attack may be taking place and what to look for.
- Credentials can be one of the many credential dumps from past data breaches or it can be that a valid credential set is being misused and appearing from multiple IPs and or appearing with and without valid sessions.
- Tools are often services that hide the nature of the attack. Commercialized examples include Bots-as-a-Service, All In One (AIO) bots, and OpenBullet but can be as simple as a few python scripts that use libraries mimicking regular user behavior. These tools are often easily detected and can be identified by unique parameters within the tool.
- Infrastructure detection used to just simply be IP addresses and lists of which ones were bad. Attackers began rotating through IP addresses and moving to commercialized proxy services. These services are competing with one another and are getting better and better infrastructure for which attackers are willing to pay more for.
- Behavior can come down to the logic of the application or endpoint and how it might be used or misused. Behavior is also what happens when things change, if IPs get blocked how fast does the attacker take to react to that? What user-agents are being used? Are they changing? Noting the attacker behavior can show what is and isn’t working to mitigate the attack. So how do we approach a specific problem and what IOCs are we looking for, given the context of the four pillars?
Let’s take Account Take Over as an example. Step one is to fully understand how the login flow works and what success and failure looks like. The next step is to baseline what a good day of standard behavior is and then begin analyzing login failure metrics. An additional metric to track is how your login success and failure rates compare to others in your industry. Once normal patterns are known, you can easily see that huge numbers of login failures can be an IOC of ATO. Similarly, paired with failures, a single username coming from multiple IPs may be abnormal.
If content scraping is a worry then looking at single IPs that are using GET method but don’t seem to be doing anything else is a great place to start. The behavioral aspect of most traffic is going to be important as well as the infrastructure, credentials, and tools.
IP addresses, Usernames and data points like login successes vs login failures certainly are low hanging IOCs. Another great place to look is User Agents or “browsers”. Most APIs are attached to mobile applications or 3rd party systems and use a developer-defined User Agent Like Android_V3 or something similar. If your APIs aren’t typically used by web users, then a Chrome 99 User Agent is an IoC that someone is attempting access. If your API is often used by standard user agents, look for the patterns. Often a group of UAs that are associated with Usernames under attack can lead to further understanding of what the attacker is doing. Continually analyze User Agents seen in both good traffic and bot attacks to find and leverage discernible patterns.
Bots cannot function without an infrastructure to run on so knowing as much about where and how traffic is hitting your API is another source of IOCs. The first step here is to compare organization source for good traffic and bot traffic. It’s highly likely that the list of providers will be quite different, with known residential proxy providers generating a higher volume of (bot) traffic, as shown in the image below.
It is difficult to say exactly what the thing or things to look for would be in any given application but, looking for indicators within each of the four pillars will help you understand if you are under attack or have been under attack and what each attack scenario might be.
If you’re going to RSA, please join my IOCs in your APIs Birds of a Feather session on Thursday, June 9th, 2-3pm.
Never miss an update!