APIs have a reputation for being the weakest link in an enterprise’s cybersecurity. This can become a self-fulfilling prophecy, as APIs’ supposed vulnerabilities make them a popular target for potential attackers and cybercriminals. This can cause all manner of security issues, as APIs can be made to divulge a wealth of sensitive information using valid API calls if your system isn’t set up properly.

Knowing the common API calls used by cybercriminals is an important part of securing your APIs and avoiding API attacks. Monitoring API traffic is notoriously tricky, as most API traffic is genuinely warranted, while some is legitimately unsafe. Knowing the exact API calls used by attackers allows cybersecurity professionals to flag or denylist suspicious API calls and traffic.

Cloud Instance Metadata API

Many cloud-based services, like cloud VMs or containers, have a local service for providing metadata or, in certain circumstances, even short-lived credentials. If an attacker is able to access the http://169.254.169.254 service, then attackers can potentially perform HTTP requests using techniques like server-side request forgery (SSRF), compromised container, or compromised process to elevate their access.

To help protect against illicit cloud instance metadata API attacks, you might blocklist the http://169.254.169.254 service entirely, while safelisting users or IP addresses allowed to have access. For authorized users, you might create a behavior model, which can be used to alert your cybersecurity team if there’s any unusual behavior from a particular user or IP. Monitoring for the creation of unusual cloud resources can also let your cybersecurity solution know that http://169.254.169.254 has been compromised.

To further protect against unauthorized cloud instance metadata API attacks, you should restrict metadata access as much as possible. You can also implement enhanced metadata security using modern security protocols like IMDSv2, or least-privilege identity and access management (IAM).

Object Storage REST APIs

Numerous APIs can sometimes be abused to read, write, or list objects stored in a directory. This can let unauthorized users, attackers, and cybercriminals export and then store sensitive data, host payloads, or exploit misconfigured access control lists (ACLs). Public GET or PUT endpoints, and list operations on object storage APIs, are especially at risk.

The PUT HTTP method is one indication that an object storage REST API is being abused. Large PUT requests or traffic coming from an unusual location are a sign that an endpoint is under attack. A large volume of list operation requests is another. Changes to the ACL are yet another sign that unauthorized users are attempting to access an endpoint.

An example of an unauthorized cloud storage REST API call might be an API call to an endpoint like Oracle’s https://objectstorage.af-johannesburg-1.oraclecloud.com without proper credentials. Calls without a ?username or access_token variable in the query could be flagged as a sign of an attempt to gain illicit access.

To help mitigate object storage API risks, implement bucket/object ACL best practices, which deny the public by default. Enabling logging using tools like S3 Access Logs or CloudTrail helps to reduce object storage REST API attacks, as it will let your cybersecurity team create a list of authorized users for an endpoint. Setting a lifetime alert on ACL resources is another way to protect an object storage REST API.

Kubernetes API Server

The Kubernetes API server is the heart of the Kubernetes control plane, giving users access to powerful operations like executing commands, forwarding ports, retrieving logs, and creating or modifying resources. Its power and broad access make the Kubernetes API server a prime target for attackers. If an unauthorized user compromises credentials or access tokens or if role-based access control (RBAC) isn’t set up correctly, an attacker can misuse the API to execute commands inside of containers, spread across the cluster, or steal secrets from other workloads.

Unauthorized access often leaves behind a trace. Unusual exec or portforward requests, API calls arriving from unexpected IP addresses or user agents, and the sudden creation of privileged pods or service accounts are all signs of malicious access. Likewise, unauthorized escalation of RBAC bindings is a strong sign that someone’s attempting to gain greater control than they should.

Implementing a layered approach to cybersecurity is one of the most common defenses against Kubernetes API attacks. RBAC should be set up to allow the strictest least-privilege principles, ensuring no user or service account has more access than they need. Access to the kube-apiserver itself should be limited, as well, ideally running it behind private networks and with strict firewalling. Service account tokens should also be rotated regularly to reduce the risk of long-term compromise. Audit logging should be enabled as well, closely monitoring sensitive operations like exec and portforward, and network policies and pod security standards should be enforced to limit movement if an attacker does gain entry.

An unauthorized API call to the Kubernetes API server might look like a request to run a shell inside a production database pod:

POST /api/v1/namespaces/prod/pods/db-0/exec?command=/bin/sh&container=db&stdin=true&stdout=true HTTP/1.1

This call is suspicious because it’s coming from an unauthorized IP address. The request to launch an interactive shell is another dead giveaway. Adding either to your cybersecurity alert system can alert your cybersecurity team should anyone attempt to access your Kubernetes API without proper access.

Authentication and Token Endpoints

Authentication and token endpoints like POST /oauth/token, Security Assertion Markup Language (SAML) assertion endpoints, or any login route used by an API are common paths that credentials applications and users use to access your systems. Because these endpoints are used to create access tokens, session cookies, or assertions that grant ongoing access, they’re a highly attractive target for attackers looking for a breach in your cybersecurity. Techniques like credential stuffing, password spraying, reusing stolen refresh tokens, or replaying single sign-on (SSO) or SAML assertions can allow an attacker to obtain valid credentials and stay inside your environment for a long time.

Signs of authentication and token endpoint abuse tend to be behavioral and contextual. A surge of failed login attempts against many accounts is one sign, as are tokens issued from unfamiliar user agents or countries, authorized tokens used by anomalous IP addresses, or unusually frequent refreshes and long-lived sessions. Any of these patterns can indicate automated credential attacks, stolen credentials being used, or sessions being hijacked.

Defending these endpoints requires both prevention and detection. Rate limiting and account-level throttling are both useful techniques to stop brute-force attempts. Multi-factor authentication for sensitive authorization flows is, as well. Short lifespans for tokens and treating refresh tokens as highly sensitive are other common methods for securing authorization endpoints. Monitoring tokens issued to unusual IP addresses or geographic regions is another way to protect against unauthorized users attempting to use authentication or access token endpoints.

Finally, logging every access token mint and use, and setting alerts for risky combinations (such as a token issued from one country and used immediately from another) are good actions to take. When suspicious activity is detected, revoke the implicated tokens, force reauthentication with MFA, and trigger an investigation.

An example of a suspicious token request might look like:

POST /oauth/token HTTP/1.1 
Host: auth.example.com 
Content-Type: application/x-www-form-urlencoded 
User-Agent: python-requests/2.31.0 
X-Forwarded-For: 198.51.100.23  grant_type=password&username=alice@example.com&password=********

This request is suspicious because the User-Agent is a generic script client rather than an official app, the X-Forwarded-For IP is new for that user, and it may be one of many similar attempts seen in rapid succession, which is known as credential stuffing. An example of a defensive response might be to flag or block repeated attempts, require an MFA challenge for suspicious accounts, log the event to be reviewed by your cybersecurity team, and, if a token is used from a suspicious IP, revoke that token immediately and send a notification to the user.

File Upload and Content Ingestion Endpoints

File upload and content ingestion endpoints like /upload, /import, or webhooks that accept external URLs are all common targets for attackers. They’re often abused to smuggle in malicious files like malware or web shells, or to trick the system into making server-side requests to attacker-controlled infrastructure. If the uploaded or ingested content isn’t handled properly, it can exploit vulnerabilities in downstream processing, such as insecure deserialization routines or image parsers with known flaws.

Improper usage often shows up with unusual patterns. Such uploads might include file types or extensions that don’t match what the service normally accepts, like executables where only image files are expected. Sudden spikes in uploads from a single account or IP address may also suggest automated probing. Errors or crashes in ingestion pipelines can also be a sign of malformed payloads crafted to trigger bugs. When webhooks or URL-based ingestion is supported, outbound requests to suspicious or previously unknown domains can point to an attacker attempting server-side request forgery (SSRF).

Defending file upload endpoints starts with strict input validation. Only accept allowlisted content types and extensions, and strip executable bits from files before they are stored or processed. All ingestion and parsing should happen in sandboxed or isolated environments so that a compromised parser cannot jeopardize the entire system.

Malware detection using antivirus or machine learning scanners can add another layer of defense. Remote fetches from user-supplied URLs should be tightly restricted, with network egress rules preventing access to sensitive internal systems. Rate-limiting uploads, logging all ingestion activity, and monitoring for spikes in volume or suspicious patterns are all common defenses against unauthorized file-upload usage.

Here’s an example of a suspicious upload request:

POST /upload HTTP/1.1
Host: files.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
User-Agent: Mozilla/5.0
X-Forwarded-For: 203.0.113.55

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="invoice.pdf.php"
Content-Type: application/x-php

<?php system($_GET['cmd']); ?>
------WebKitFormBoundary--

This upload is suspicious for several reasons. The filename being uploaded is named invoice.pdf.php, which is a PHP script masquerading as a PDF. The content type doesn’t match the claimed extension, either, and the payload includes a web shell. If such a file were stored and executed on a misconfigured server, it could give the attacker remote code execution. Defenses should detect the mismatch, block the upload, and alert security teams to the attempt.

Final Thoughts on Common API Calls in Cybersecurity Attacks

Defending APIs against cyberattacks isn’t as straightforward as other areas of cybersecurity, where it’s often possible to buy an out-of-the-box solution. Instead, cybersecurity for APIs has a lot more to it, as it requires differentiating between valid traffic and unauthorized usage.

Knowing what kind of API calls malicious attackers commonly employ is an integral part of defending your API ecosystem, giving API managers and cybersecurity teams an idea of what to look out for.

As you can see, protecting your APIs requires more than just pasting API calls into your security system, as everyone’s system is a little different. Instead, the principles and strategies covered above can be applied to any system, regardless of what tooling you use.