Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
The Evolution of Cloud Forensics and Incident Response
With the adoption of cloud infrastructure rapidly changing our attack landscape, we find ourselves with SOC and IR teams asking for some of the same visibility they had in the data center in the cloud. In some scenarios, the traditional SOC/IR tools are hardly practical or cost-effective. Due to the ephemeral nature of cloud infrastructure, a lot of the traditional security operations motions need to evolve to replicate the high-fidelity forensics that have given security teams the peace of mind to know what happened, on what host and what traffic traversed the cloud. In this blog we will leverage several native and third-party tools to capture malicious activities that can be performed on a cloud host to provide guidance on cloud forensics and the evolution of security operations and incident response.
For this blog series, we will be focused on AWS and EC2 hosts, but many of the tools will be public and private cloud-agnostic. The initial visibility we would want aligns with tools traditionally used for configuration management. Who modified the firewall? What rules were changed? What were the permissions given to an IAM role? For this visibility, we will leverage Palo Alto Networks Prisma Cloud to replicate monitoring of an environment that an SOC would want in a centralized dashboard.
Figure 1 - AWS Environment with Prisma Cloud Defender and Cortex XDR Prevent Agent
Moving further into the visibility of the cloud, we will deploy a lightweight service that runs on the actual cloud host that leverages a four-dimensional behavioral model that looks at process activity, system calls, file system and outgoing network activity. This will all talk to a single console and incidents will be recorded from the behavioral model. In addition to some static and behavioral analysis we will see what a baseline is for “normal.” We will also be given host, container and image vulnerability data that will enable us to understand the attack surface even further in the cloud. We can also get visibility into CIS benchmarks and several regulatory compliance violations. The Prisma Cloud Defender is deployed at the host level with a simple curl script and can be deployed using automation with minimal administrative overhead.
Figure 2 - [Defender Radar Pop Out]
Much of the aforementioned functionality will be from a sole product set but as we have seen repeatedly, there is no silver bullet for the requirements that come from multiple business units, security, infrastructure, DevOps and any other stakeholders who want to protect a company’s assets. For some higher fidelity endpoint detection and response, we will leverage the Palo Alto Cortex XDR Prevent agent to get more granular visibility of processes and child processes spawned as well as doing more in-depth host-level threat hunting on our AWS EC2 instance. This will also allow for terminal access from the Cortex XDR dashboard to perform remediation if necessary.
Figure 3 - [Screenshot of Cortex XDR Dashboard Showing Parent/Child Process Chain on an EC Host]
The beauty of the product set that we will be leveraging for this blog series is that there is very little lift to get the administrative consoles set up. Both are offered as a SaaS and neither requires any modifications to an on-prem or cloud environment. In a matter of minutes, we can onboard a cloud account to ingest the metadata of the configurations and flow logs of AWS, GCP, Azure and Alibaba. This will provide a large set of features that can be mapped back to security operations workflows. A short list is provided below:
MITRE released this attack matrix for Enterprise Cloud that I feel is a good reference for walking through some of the aspects of an example enterprise cloud attack that we can identify once we have Prisma Cloud deployed. For this blog series, I’ll be covering techniques in initial access, persistence, privilege escalation and defense evasion tactic phases.
Figure 4 – MITRE Att@ck Matrix for Enterprise Cloud
Imagine a scenario where a developer has cloud account credentials compromised. Without setting up two-factor authentication in AWS, Azure or GCP, a login from an anomaly IP address can go undetected if alarms aren’t set up in the native console or some type of UEBA solution. The credentials are used to log into the AWS console from a Ukrainian IP address. At this point, Prisma Cloud will capture CloudTrail logs and correlate the source IP and country of administrative tasks performed. The user’s console login will be flagged as a location-based anomaly and an “Account Hijacking Attempt” alert will be generated in the Prisma Cloud alerts table. At this point, you could send those Prisma Cloud alerts to a ticketing system like ServiceNOW or JIRA or notify security personnel via Microsoft Teams, Pager Duty or Slack. But for the purposes of this blog, we will allow the attacker to continue down the path of malicious activity. Along the way, we will demonstrate visibility across the attack chain. In a future blog, we will create a finely tuned policy.
Figure 5 - [Compromised AWS User Ukraine Login] Account Hijack Attempt Alert Investigation (Prisma Cloud Enterprise -> Alerts -> Account Hijack Attempt Alert
Figure 5a - [Compromised AWS User Ukraine Login With Map] Account Hijack Attempt Alert Investigation (Prisma Cloud Enterprise -> Alerts -> Account Hijack Attempt Alert -> Investigation Map View
Once attacker uses the stolen credentials to log in into the AWS console, he or she has administrative access of the cloud infrastructure and can start to look through the EC2 dashboard for potential hosts to compromise. At this point, the attacker notices an EC2 instance of interest and wants to get root access to create a new admin user and connect via SSH. The AWS credentials used have access to attach an IAM policy to the EC2 instance that allows root access through the web UI of AWS via the Amazon SSM agent service that is enabled on the EC2 host and allows command line access through AWS Systems Session Manager.
At this point the attacker now has full root access to the EC2 instance and will start to conduct activities on the cloud host level. Prior to having a Defender deployed on the EC2 host, we were only leveraging the CSPM features of Prisma Cloud. The Defender adds host- and container-level visibility. This allows us to see every SSH login event and sudo command performed. The screenshot below shows that the attacker ran as root via the Amazon System Manager Agent process to create a new user “admin.” Prisma Cloud has activity monitoring capabilities via the runtime host protection functionality. Runtime host protection is designed to continuously report an up-to-date context for the EC2. You can set alerts for filesystem, process, network, log file events and more. Some events, such as process executions, can be blocked. A screenshot of the Host Observations tab in the Prisma Cloud GUI is provided in the figure below showing the ssm-agent-worker process running commands as root to create the admin user.
Figure 6 - Host Observations (Compute -> Monitor -> Runtime -> Host Observations->Select EC2 Host With Defender Deployed->App tab)
In addition to creating the new user, attackers generate their own SSH keys on the EC2 instance and can copy those private keys via the web GUI console so the SSH keys never leave the compromised cloud host. The keys are left stored on the instance so the only way we can identify that someone generated their own SSH keys is by viewing the Prisma Cloud Compute event logs, which are recording every command performed on the EC2 instance.
Figure 7 - [Secrets Modified Event] (Compute -> Monitor -> Events -> Host Activities
It should be noted that you can enable Session Manager logging in the native AWS tools for commands run through the web console, but this is not enabled by default: it was the attacker who enabled this connectivity, not the AWS admin. The fact the attacker was able to assign the IAM role for SSM quick setup to this device emphasizes that overly permissive IAM privlages continue to be a challenge, as it was on prem, but it’s even more amplified in the cloud.
Figure 8 - Enable AWS System Manager Session Logs –AWS Systems Manager->Session Manager->Preferences Tab->Enable CloudWatch Logging
Figure 9 - Host Observations (Compute -> Monitor -> Runtime -> Host Observations->Select EC2 Host With Defender Deployed-SSH Events Tab)
Now the attacker has a new privileged account local to the EC2 and can SSH with the newly-generated private key. But upon attempting to login, the attacker realizes the security group needs the IP address allowed on port 22 inbound from the Ukraine. Since they can modify security groups with the AWS console web credentials, we can see the attacker making that change to the security group as part of the audit trail view in Prisma Cloud. This will show that a valid account made this change so it will not flag an alert on Prisma Cloud, but we are able to do an investigation to show when the change was made, to which security group and by which admin.
Figure 10 - Audit Trail of Modifications to a Security Group by Compromised Cloud Admin
In part two of this series, we will begin to exfiltrate data from the EC2 host and identify how Prisma Cloud ingests flow logs and can identify large volumes of traffic traversing the public cloud to the attacker’s public internet IP. Additional malicious activity will also be performed on the cloud host.
June 11, 2020
A how to guide using Gitlab, Hashicorp Terraform Cloud, AWS EKS and Palo Alto Networks Prisma Cloud to build and secure a Kubernetes cluster.
July 22, 2020
An attacker could use a poisoned docker image to break out of a container.
September 16, 2020
Palo Alto Networks Prisma Compute can help minimize the risk of deploying untrusted images.
Let us know what you need, and we will have an Optiv professional contact you shortly.