Anatomy of an API Attack: Applying the MITRE Knowledge Base to API Threat Modeling

The MITRE ATT&CK knowledge base of adversary tactics and techniques forms a powerful foundation for cybersecurity threat models and methodologies. The comprehensive and current cyber security threat information effort, launched in 2015, has spurred an active and growing community -- available to any person or organization at no charge – serving both the private sector and governments globally.

At the recent API Secure conference, I was part of an expert panel discussion that addressed applying the MITRE framework specifically to API threat modeling. I spoke with Upendra Mardikar, Chief Security officer at Snap Finance. Here’s a transcript of our informative presentation.

Renata Budko: According to a 2020 study published by the University of California, Berkeley, more than 80 percent of companies now use the MITRE framework for cybersecurity. Clearly, most security professionals are familiar with the framework, but applying it to API security is relatively new.

As Head of Product at Traceable AI, I tend to look at things from both the engineering and technical and attacker standpoint, as well as a defender and a practitioner of security coaching. The good news is that there are now many proven approaches and new models of threat tactics and techniques in MITRE that we can use to protect our APIs.

Upendra Mardikar: At Snap Finance we are in the buy now, pay later (BNPL) lease-to-own financing business. As a CISO at Snap Finance, I put a lot of emphasis on threat modeling and analysis. I find that Snap is not unique in that regard. As some background, I have about 96 patents, and prior to Snap, I was with American Express, Visa, and PayPal running multiple security organizations.

Budko: Upendra, since you have worked in cybersecurity in executive roles for such a long time, I’m sure you have used MITRE in your practice quite a bit. Can you tell us about the history of the framework?

Mardikar: MITRE is a non-profit, mostly government-funded research organization headquartered in Bedford, Massachusetts and McLean, Virginia. It was spun out of MIT Lincoln Labs more than 50 years ago. They have a cyber security division and team that examines regular security attacks. That ranges from anything from identifying an IP addresses involved in attacks to the signature of a computer virus.

But MITRE takes a step back and looks at the behavior of an attacker instead of just a specific signature or IP address. It looks from the attacker perspective and discerns the behavior.

For example, many of us are familiar with Common Vulnerabilities and Exposures (CVEs). But the MITRE attack profile examines the behaviors. MITRE teams are familiar with the tactics, techniques, and procedures (TTPs) of the attackers, such as when an attacker launches an attack, at what particular point, and the patterns in the ways they attack. These are the tactics.

MITRE takes a step back and looks at the behavior of an attacker instead of just a specific signature or IP address. It looks from the attacker perspective and discerns the behavior.

If you drill down deeper for each tactic, they then discern techniques. It’s a beautiful term that MITRE came up with. And then there are sub-techniques. For example, APT3 is phishing as a technique attackers can use. A famous technique is APT29, called Cozy Bear. And it’s claimed that SolarWinds attacks, for example, were because of APT29.

There are, if you will, cookie-cutter tactics and techniques that attackers use. So instead of looking at your security architecture and deploying best practices, MITRE flips the paradigm to  look at it from the attacker behavior perspective.

Budko: Upendra, would it be fair to say that MITRE fundamentally is two things. It’s looking at the attackers from the behavior perspective and representing their behaviors as an ontologyy of tactics and techniques. And secondarily, it’s a mechanism for sharing this information about newly discovered attacks like Cozy Bear.

Mardikar: Yes, the attack framework contains and shares using precise language all documented behavior attackers or adversaries. ATT&CK stands for adversarial tactics techniques and common knowledge.

In the security community, as you know, there are so many new things that keep coming. So we need a common language to communicate. STIX is a machine-to-machine language that MITRE, and the brilliant people over there, came up with. TAXII is the format in which they communicate.

With that, the security professionals, the vendors, all of them, talk the same language. We, as a community, can come together to defend ourselves. The red team and the blue team, the purple teams, all of them can come together. So, that is the whole premise of what the MITRE attack framework has given us.

Budko: Let’s double-click into the elements of the tactics that MITRE includes. And I know there are a lot, and we see over a dozen. In terms of applicability to APIs, what have you seen in your practice?

Mardikar: In the MITRE attack framework is something called inspector. It takes the attacker perspective. Attackers are typically lazy and so they use a cookie-cutter formula, which --  just by looking at different patterns across multiple organizations for those researching different attacks -- MITRE has tracked. They say, “Hey, these are the typical tactics an attacker uses, and these are some of the techniques they use.”

An attacker needs to know what your system is to get some initial access. Is there, for example, a command-and-control center? Now, not all the same steps will be followed by an attacker. Some of them will be followed. Sometimes they do reconnaissance and the privilege escalation and then go into the discovery. There are multiple formulae an attacker uses. And they may not use all the techniques across all of these.

Budko: The TTPs depend on which platforms the attackers are trying to explore. Obviously, procedures that would work for Windows would not work for mobile iOS. But how can MITRE be used today for discovering APIs attacks?

Mardikar: The MITRE attack framework and the brilliant work by very smart people, the community-based people, contribute to it. As of now, there is an enterprise level. MITRE is saying, “Hey, if you are an enterprise, how can we split that into platforms, due to the multiple platforms that enterprises use?”

An enterprise can have Windows, Linux, Mac OS -- all these platforms. And, of course, we have entered the mobile era and the cloud era, with Office 365 and AWS, so all these different cloud service providers. And they also have apps and services going into containers.

So, what we are proposing as a new addition to what MITRE does is to go into the cloud and containers level for the attack framework. Now, when you are looking up mobile, obviously, that is iOS and Android. There are industrial control systems and different platforms for various industries.

So, we are proposing that we can also have an API as one of the considered platforms. Now, some people will say, “Hey, an API is not a platform.” I tend to agree with that. An API is not a platform. There are three or four ways an organization can deliver APIs: As an API gateway, a .JAR file, and as a sidecar proxy because we are going at the container level.

I propose that we have MITRE consider APIs as either one of the covered platforms or as one of the techniques, in the tactics. It could be one of the techniques, so that we can see the behavior of an attack on APIs. There will be more to come as to why we think that is the case and I would love to get people’s input as to how we go further with this conversation.

--Upendra Mardikar

Because the attackers are going at a container level, there could be something at a side proxy level. Or there could be something that is at an API gateway level. There could be something at a .JAR or an interceptor pattern level. So, that is what we are talking about. Or it can go at the protocol level, for example, at the GraphQLs.

I propose that we have MITRE consider APIs as either one of the covered platforms or as one of the techniques, in the tactics. It could be one of the techniques, so that we can see the behavior of an attack on APIs. There will be more to come as to why we think that is the case and I would love to get people’s input as to how we go further with this conversation.

Budko: I would argue that even if there is an overlap between the architecture -- how APIs are delivered from the standpoint of the attack and anatomy – that the APIs still represent a separate set of attack vectors.

Mardikar: Exactly. I agree with that statement. And we will talk about why.

Budko: Before we go there, I want to ask the audience what percentage of web traffic goes over APIs these days? Your choices are 33, 56, 83 or 95 percent. It’s 83 percent. So the majority of Internet traffic is APIs these days. Second, what’s now the single most frequent attack vector? Ransomware, phishing, API abuse or insider sets? Gartner predicts it is or soon will be API abuse.

APIs are obviously at the center of what we do every day. It means that all the SaaS community, all the Internet traffic, all the value delivered via APIs is not going unnoticed by the adversary community, obviously. So, it’s very important for security architects to – like MITRE -- look at the behavior of the attackers. It’s what allows us to do a better job of prediction, detection, and prevention. The whole resistance to an adversary environment will be much more robust if we are able to look at the attacker behavior.

Mardikar: That is absolutely right. And just to add a little bit of color to what Gartner is saying, there is an API-first movement in many organizations. Most of us engineers are being asked to write everything as an API, expose everything as an API. So 83 percent, that number will be a lot higher as we continue on the API-first track.

When we look at everything as an API, there are three primary drivers for finding the APIs. The first is, what is happening? Are there multiple verticals in the organizations?  Are there certain segments of the business? If the product teams are asking to expose everything as an API, are they being built by different organizations? You will likely have multiple microservices and multiple systems that are exposed as APIs and built by different organizations.

Secondly, APIs are not as visible as webpages. The consequence of that is when they’re not visible, you won’t be able to see what kind of leakage of information there could be. You could, for example, have a webpage that shows Social Security numbers or passwords. We need more mature tools to look for those kinds of things.

So, when APIs are created by different organizations and are not visible, and when an API is used for one microservice, you don’t know what is happening with the API without that microservice.

APIs are multi-purpose. Some are meant for consumer consumption, but tons of APIs are used primarily for partner consumption. There may be a supply chain where you are talking to vendors or to another third-party. There are multiple APIs that go into this ecosystem. Because of this, data can get exposed to the partner intentionally. For a credit card number for the credit card processor, for example. But that then also increases your attack surface.

There are three trends at work here. First, the APIs are developed by different organizations. That means there is no uniform API inventory and people are still building on top of that. A new level of maturity needs to be there. The second thing is, the APIs are not as visible as webpages. And then the third thing is that more information, arguably, can be leaked out of such poorly understood APIs.

Because of the increased API-first mentality at so many organizations it now becomes supercritical for us to look at API security. Obviously, we are going to follow security best practices to make sure there is authentication and all that. But how do we -- while an attacker is doing reconnaissance, trying to get initial access into the APIs – use the MITRE methods to look at all the APIs that are exposed from the adversarial behavior perspective? It’s become very important therefore to extend the MITRE framework and its community-based approach to the worldwide challenge of defending APIs.

Budko: How does API discovery map to MITRE? What should that look like?

Mardikar: We are making the case that we should include APIs in some shape or form either as a platform or even as a technique in the MITRE framework. That is what we are arguing for as organizations are moving rapidly toward APIs.

So, what should we do as security practitioners? First, we need to be familiar with the MITRE attack framework. There are lots of tools there, such as Inspector. There are also very good and intuitive YouTube videos that talk about how to use Inspector. So, get familiarized with all of that. Secondly, learn what kinds of APIs are in your organization. Learn about the industry-specific APIs, too. What are the different kinds of attack behaviors that your industry is seeing? Is it safe to exchange sensitive information using those APIs, internal and external?

Discover what APIs are being exercised around your business flows. Are there some financial outcomes, sensitive data, or ransomware that could come directly through the APIs? This means being able to understand the API behaviors, instead of just looking at the IP addresses or signatures. By identifying API behaviors, you can gather the indicators of a compromise and hunt for threatening players.

You will want to identify susceptible API and then determine the behavior of an attacker. Next, you’ll want to translate that behavior into tactics. Is this a recon? Is this initial access? What tactic is an attacker using? The techniques are going to be very similar to what we see with such things as phishing. All these things are techniques. Those can control APIs, but the procedures, Renata, will be organization specific.

Learn what kinds of APIs are in your organization. Learn about the industry-specific APIs, too. What are the different kinds of attack behaviors that your industry is seeing? Is it safe to exchange sensitive information using those APIs, internal and external?

These are some of the API discovery steps we can apply MITRE to for API security. We can concretely identify the behaviors of an adversary, understand and map the tactics, and then detect the techniques and sub-techniques around API risks.

Budko: Our common API weakness database provides some examples of techniques to be aware of. For example, I know broken access control has been top of mind for us at Traceable as we deliver the API security module for our customers. Finding the broken access control is a very common technique that our customers see in their environments and that they need to identify as a part of adversary behavior. What other examples do you find common as API exploiting techniques?

Mardikar: A lot of organizations have fallen prey to security misconfigurations, for example. The current trend is for more software-defined networks, software-defined infrastructure, and software-defined enterprises. But what is happening is that when you’re defining all this software and infrastructure, those are configured using APIs.

Because everything is an API, the security configurations are delivered over the networks and potentially to multiple clouds – private, public, virtual private clouds, and hybrid clouds. Some of us have old data centers. And all these software-defined infrastructure configurations are exposed as APIs. A common technique is to abuse the security and that can lead to misconfigurations that might expose quite a few things.

Budko: Makes perfect sense. These various techniques, how do they map back to the tactics like initial access? You typically see that with broken authentication. Like sidewise  movement, it's probably injections that contribute to that. Data exfiltration , you can frequently see that executed by insecure deserialization. And, of course, you mentioned the security misconfiguration that is so pervasive. It probably can be used in a tactic in many different stages of attacks.

From the standpoint of the MITRE framework, how would it help defend against these vulnerabilities, Upendra?

Mardikar: In software production, what happens is in the effort to deliver and have our own priorities, sometimes we don’t pay attention to the non-production side as much as to the production side. We have to make sure that when we are exposing anything to the internet – whether it’s in production or pre-production – that the same security controls are present.

In a classic example, for a Bay Area social platform, a velocity or rate check did not happen. A typical misconfiguration. That is a classic API attack  essentially.

Budko: Because it’s a classic attack, we can also easily interpret that in the form of the tactics or behaviors of an adversary that MITRE is proposing. They have initially accessed the system due to the API vulnerability then they have executed an attack by account takeover. They were able to access admin credentials, and of course, because of what happened is root level control of all the systems. It was executed by an API in terms of analyzing the adversity behavior. I would say that it’s very close to what they would have always done. Same as any other style attack, whether they were cloud or enterprise or even mobile.

Mardikar: Absolutely.

Budko: How should we use this knowledge as practitioners on the blue team side? How to defend our systems from the adversaries and all the analysis of their behavior is mostly to inform our mitigation techniques. There are a few examples here of what mitigations can be used with relations to APIs. Can we double click on some of this, Upendra?

Mardikar: We can talk about credentials access protection. That is something people will be seeing. As we go into OpenID Connect, APIs are going to need some kind of authentication.

One of the things that we can double click on is typical credential stuffing or credential dumping. There are multiple flavors, Renata. But it’s one of the lax practices that we are seeing, because most of the people use the same passwords across multiple sites, right?

Budko: Okay.

Mardikar: At a practical level, if you have a site A or site B, what people see is lots of users use the same passwords across those sites. And God forbid, if one of the companies or sites gets compromised, their usernames and passwords are dumped. That can happen.

What attackers are doing is they are replaying all these credentials. It’s a very simple technique for APIs abuse. And because it is all programmable, your API is programmable, you’re accepting the username and password on an API basis. You need to make sure for that particular technique that people are guarding against it.

That means you need a threat-informed defense, so you know what the threat is and you are specifically applying particular controls for that API risk. What we are saying is that these APIs are being exposed across multiple organizations. You need to create defenses for those APIs and behaviors.

One of the takeaways here is that you can use the MITRE ATT&CK knowledge base of adversary tactics and techniques specifically for APIs. Look at cyber threat intelligence. Look at your detection capabilities and look at the threat hunting. Employ your red and purple teams to test those controls by combining all these things together. That becomes more like an API, it could be a platform like we talked about. And then applying MITRE to the API problem is just like a platform or maybe as a technique. That’s the proposal, Renata.

Budko: Makes perfect sense. Thank you, Upendra.

(Renata Budko is Head of Product at Traceable AI.)

You can follow Renata on Twitter and also learn more about Traceable AI and how it observes, analyzes and secures APIs. Depending on your role and the needs at your organization, there are multiple options to get started with Traceable AI and its many options for observability and API security:

• If you’re a CISO or DevSecOps security leader and want to evaluate your API security risks, try the API Security Posture Assessment.
• To start your journey, sign up for a Free Tier and learn all about your APIs — internal, external, third-party, and even the shadow or rogue APIs you may not even be aware of.
• If you want to compare different API security solutions in the market, check out the API Security Tools comparison guide.
• You can also view a demo or book a meeting to learn more and ask your questions on how Traceable can meet your API observability and security requirements.