Unusual Number of Modifications to Cloud ACLs

Description

Looks for a large number of Security Group ACL changes in a short period of time for a user.


Use Case

Advanced Threat Detection

Category

Account Compromise, IAM Analytics, Data Exfiltration, Network Attack, SaaS

Security Impact

The risk that this detection intends to reduce is the compromise of an IaaS environment, where all of a sudden Security Group (Firewall) ACLs that have existed to protect an environment are thrown open, allowing either outside connections in, allowing data exfiltration, or allowing lateral movement from one group to another.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Persistence
Privilege Escalation

MITRE ATT&CK Techniques

Valid Accounts

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Leviathan
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
menuPass

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 a spike in the number we're monitoring... it's nearly impossible for the math to lie. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

How you handle these alerts depends on where you set the standard deviation. If you set a low standard deviation (2 or 3), you are likely to get a lot of events that are useful only for contextual information. If you set a high standard deviation (6 or 10), the amount of noise can be reduced enough to send an alert directly to analysts. If your orchestration tools will perform these actions, and they aren't a part of the baseline (or they're very rare in the baseline), those could create false positives. You might opt to whitelist those tools, or alternatively to make a part of the response verifying in your change management whether those tools were scheduled.

   How To Respond

When this alert fires, you should 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. In particular, look to see what the ACL changes were, to see what new access has been allowed. Check your VPC Flow logs to see if data was sent over those newly allowed connections.

   Help

Unusual Number of Modifications to Cloud ACLs Help

This example leverages the Detect Spikes 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 Unusual Number of Modifications to Cloud ACLs

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.
With our dataset onboard, we then filter down to just the events indicating a modification of ACLs
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Next we use stats to summarize the number of events per user per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

AWS Data

First we bring in our basic dataset, AWS CloudTrail logs that are filtered for ACL modification events.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Next we use stats to summarize the number of events per user per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

GCP Data

First we bring in our GCP Audit logs, filtered for ACL modification.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Next we use stats to summarize the number of events per user per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

Azure Data

First we bring in our Azure Audit logs filtered for ACL modification.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Next we use stats to summarize the number of events per user per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

Screenshot of Demo Data