PantherFlow Examples: Threat Hunting Scenarios
Last updated
Was this helpful?
Last updated
Was this helpful?
Let's say we've received a alert about an EC2 instance being potentially misconfigured. From the alert, we can pull the associated AWS instance IDs. Then, we can search across all of our AWS logs for activity on those instances.
The statements above leverage:
functionality
Operators: , , , , and
Functions: , , , , , , , and
While threat hunting, it's common to need to pull values from one table and pivot to searching those values in another table. The queries below fetch IP addresses from the VPC Flow logs table, then search for them in Okta System logs.
The statements above leverage:
This query searches AWS logs for an IP address that matches a regex expression.
The statements above leverage:
Results:
5866
34.222.253.62
AWS.CloudTrail
184
34.222.140.16
AWS.CloudTrail
176
34.222.42.181
AWS.CloudTrail
171
34.222.87.204
AWS.CloudTrail
88
34.222.241.235
AWS.CloudTrail
...
The event tells us that an actor named ariel.ropek
has created API keys for a new user called snidely-whiplash
. Let's investigate to see if this behavior is a false positive or real compromise.
First, let's look at ariel.ropek
's activity during the hour surrounding the alert:
Results:
Interesting! We see that not only did ariel.ropek
create a new user named snidely-whiplash
, but that they attached an AdministratorAccess
policy to it:
Let’s add snidely-whiplash
to our query to view their activity:
Results:
There are many more results when snidely-whiplash
is included—we can see that user ran commands in EKS. They created a new role, associated the AmazonEKSClusterAdminPolicy
to it, then assumed the role under a new session name, snidely-whiplash-session
.
Results:
Looking at the p_action
column, we can see that using snidely-whiplash-session
, the user created a Kubernetes pod (create pods
). Clicking into the full event, we see the pod they created is privileged:
At this point, we can conclude that this is very likely a malicious actor. In sum, we've discovered:
An AWS user (ariel-ropek
) created a new user (snidley-whiplash
) with admin privileges.
snidley-whiplash
pivoted into EKS and elevated their privileges there, becoming a cluster admin.
They created a privileged pod in EKS.
Results:
In the visualization above, the attack chain can be tracked from right to left, starting with ariel.ropek
's actions.
functionality
Operators: and
Functions: , , , , and
Operators: , , , , and
Functions: , , and
In this scenario, we've received an alert for a match on the Panther-managed detection, which runs over CloudTrail data and alerts when an AWS API key is created for an AWS user by another user.
This threat scenario is also , as well as in the Panther blog: .
Now that we know the user took action in EKS, we need to use to expand our search to include EKS Audit and Authenticator logs.
CloudTrail, EKS Audit, and EKS Authenticator logs each have a different schema; however, we can use to create a data model that maps these log sources to common actor
and action
fields:
We can view the full attack chain in a chart with :