New IaaS API Call Per User

Description

Looks for users that are using IaaS APIs that they've never used before.


Use Case

Advanced Threat Detection, Insider Threat

Category

Account Compromise, IAM Analytics, Insider Threat, SaaS

Security Impact

The risk that this detection intends to reduce is the compromise of an IaaS environment, where all of a sudden an account starts accessing APIs that they haven't normally before (such as creating keys, creating AMIs, changing ACLs, etc.). Assuming that the user has not changed roles, and that new orchestration tools are not being used, this would suggest that credentials have been created or compromised, and are in control of an adversary. This could result in potential data leakage, data deletion, or cost run-up.

Alert Volume

High (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Execution
Credential Access
Collection
Exfiltration
Technical Information Gathering

MITRE ATT&CK Techniques

Determine 3rd party infrastructure services

Kill Chain Phases

Actions on Objectives

Data Sources

Audit Trail
GCP
Azure
AWS

   How to Implement

Assuming you use the ubiquitous AWS, GCP, or Azure Add-ons for Splunk to pull these logs in, this search should work automatically for you without issue. While implementing, make sure you follow the best practice of specifying the index for your data.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

Specifically for IaaS, these vendors have many APIs (and create new ones regularly!), so it's generally best to tune over time for which APIs you actually want to be emailed about. Leave the rest for context, or to aggregate risk.

   How To Respond

When this alert fires, you should look at what APIs were called. We've excluded some of the basic inaction ones (such as DescribeInstances), but the severity of the event will vary based on the severity of the API calls. The natural next step is to call the user and see if they expected this behavior. If the user cannot attribute this activity, it is best to reset the keys and continue your investigation to see what occurred.

   Help

New IaaS API Call Per User Help

This example leverages the Detect New Values search assistant. Our example dataset is a collection of anonymized AWS CloudTrail logs, during which someone does something bad. Our live search looks for the same behavior using the very standardized index and sourcetypes for AWS CloudTrail, GCP and Azure Audit, as detailed in How to Implement.

SPL for New IaaS API Call Per User

Demo Data

First we bring in our basic demo dataset. In this case, anonymized AWS CloudTrail logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

AWS Data

First we bring in our basic dataset. In this case, AWS CloudTrail logs, filtered for individual APIs that we want to pay close attention to.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

GCP Data

First we bring in our GCP Audit logs.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Azure Data

First we bring in our Azure Audit logs, filtering out some of the noisy read-only operations.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Screenshot of Demo Data