Cloud Security Use Cases: Why You MightMiss the Forest if You Ignore the Trees

WHITEPAPER

www.paladion.net

Author:VINOD VASUDEVANCTO - Paladion

Securing cloud infrastructure is different than securing datacenters.

On the surface, Cloud security breaches look similar to traditional datacentre breaches. A cybercriminal launches an attack. That attack successfully breaches the system’s perimeter. And from there, the cybercriminal works towards an objective like data exfiltration, fraud, extortion, IP the�, or another variation of cyber warfare. However, beneath these surface similarities, Cloud breaches and datacentre breaches operate in di�erent ways and must be managed di�erently.

This whitepaper will explore:

Why Cloud infrastructure must be defended di�erently than traditional datacenters

The unique methods that cybercriminals deploy to attack the Cloud

How to detect Cloud attacks and e�ectively respond

WHY IS CLOUD SECURITY DIFFERENT?02

Introduct ion

“ Securing cloud infrastructure is

different than securing datacenters ”

Cloud Attacks vs. Datacentre Attacks - Similar Outcomes, Different Methods

There are two primary reasons why cybercriminals attack the Cloud di�erently than they attack datacentres.

First, Cloud deployments have a di�erent technical stack than traditional datacentres. Hence, cybercriminals adopt new and innovative technical methods to attack, probe, breach, and navigate Cloud deployments.

Second, popular Cloud services like Azure, AWS, and GCP exhibit rapid change, and internal security teams face di�iculty maintaining alignment. The complexity and constant evolution of Cloud infrastructures o�en lead to configuration errors that cybercriminals can exploit.

How Cybercriminals Attack the Cloud

A review of the recent Capital One breach provides a clear example of how Cloud attacks play out. Capital One breach is only used for illustrative purposes here. The cybercriminal behind this attack had a deep understanding of Cloud components and the unique ways they could be exploited. It was a sophisticated attack and complex for any organization to detect.

It is easy in hindsight to say that the attack could have been avoided with a better configuration of Cloud components. But we tend to overlook the complexities of gaining visibility of hundreds of configuration settings and thousands of events in a rapidly changing Cloud environment.

WHY IS CLOUD SECURITY DIFFERENT? 03

04 WHY IS CLOUD SECURITY DIFFERENT?

Here is what the attack looks like based on information available from

https://www.justice.gov/usao-wdwa/press-release/file/1188626/download

https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/#more-48424

The attacker used a misconfigured WAF to run an SSRF attack. An SSRF attack can be used to run URL based queries.

The attacker ran the following query using SSRF: http://xyz.com/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.

The attacker used the query http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name against AWS metadata to capture the credentials for the role

The attacker then used this role (that had excessive privileges) to list S3 buckets.

Once the attacker learned the structure and content of the S3 buckets, the attacker ran sync command to copy the contents of each targeted folder with credit card and other critical information to a local folder owned by the attacker.

The attacker used a combination of TOR network and valid IP addresses through the attack.

It is clear that the attacker constructed the attack exploiting di�erent components in AWS including WAF, Identity and S3 storage. In order to detect and respond to such breaches, we need to have specific use cases for each service component in the Cloud including compute, storage, security, identity. In addition to this, we should be able to combine the service component level use cases (attack trees) and derive the bigger picture of the breach(the forest). In the following section, we provide a snapshot of di�erent Cloud service components and potential use cases.

“ In Cloud security,it is easy to miss the

forest when youignore the trees ”

A View of the Trees: Cloud Security Use CasesThe table below o�ers a sample set of use cases for common Cloud service components in Azure and AWS. These are not exhaustive and captured as illustrative for Azure and AWS. Similar use cases apply to GCP and other Cloud providers.

05WHY IS CLOUD SECURITY DIFFERENT?

AzureComponent

AWSComponent

CloudService Sample Monitoring Use Cases

Virtual Servers Password brute forceChanges to security policies including password, audit, and accounts Changes to server configurations including scheduled tasks, registry, and service changesAttempted policy and configuration violationsAnomaly in the number of VMs created and deleted as compared to baseline

VMs (Windows, Linux)

EC2 Instances (Windows, Linux)

Storage Permission changes including public access to storage accounts or S3 bucketsQuery for listing of S3 bucket objects or storage account blobs from unusual or blacklisted user accounts, IP address, and URLSync or copy of S3 objects or storage account blobs from unusual or blacklisted user accounts, IP address, and URLCreation of new S3 objects or storage account blobs from unusual or blacklisted user accounts, IP address, and URLDeletion of S3 objects or storage account blobs from unusual or blacklisted user accounts, IP address, and URL

Storage Account

S3

WHY IS CLOUD SECURITY DIFFERENT?06

AzureComponent

AWSComponent

CloudService Sample Monitoring Use Cases

DB Databases or tables created or deleted by anomalous accountsDatabases or tables created or deleted from a blacklisted or anomalous IP address or URLPermission changes to databases or tables from anomalous IP or suspicious accountsTime-based anomalous execution of critical commands on a database or table. Select * on a critical table at an unusual time

Count based execution of anomalous commands on a critical data table. A high count of inserts on a critical table

Database (MS SQL, MySQL, Postgres)

RDS (Aurora, MySQL, Postgres, MS SQL)

Web Suspicious HTTP Methods observedWeb pages accessed from blacklisted sourcesAnomalous requests to new pagesDirectory traversal from anomalous IPs/URLsDetection of backdoor shell

App Services Elastic Beanstalk

Networking Lateral movement based on access volumetric anomalies Data Exfiltration based on data size volumetric anomalies Insider threat or external account takeover based on scan pattern detectionChanges to network access rules from an unusual IP or geographyAccess to VMs from suspicious IP or geography

NSG Flow Logs VPC Flow Logs

-

WHY IS CLOUD SECURITY DIFFERENT? 07

AzureComponent

AWSComponent

CloudService Sample Monitoring Use Cases

Identity Successful logins from unusual geographiesVelocity of logins from di�erent geographies within a short durationAnomalous assume role callsChanges to IAM authentication and authorization policiesTime based anomalous IAM API activity

ActiveDirectory

IAM

Security SQL injection, cross-site scripting, directory traversals, and other OWASP top 10 attacksSSRF attempts to http://169.254.169.254/latest/meta-data/iam/security-credentials/Outbound or inbound communication with unusual or blacklisted user accounts, IP address, and URLUnusual HTTP request method observedWebserver scanning detected with blacklisted user agents

Application Gateways

WAF

Console Velocity of logins for admin user from multiple geographies in a short time frameMultiple failed login attempts for same user indicative of brute force attemptsSuccessful logins from blacklisted sources Changes to administrator groupsChanges to 2FA settings

Console Console

Don’t Miss the Forest: A Holistic View of the Breach In Progress

-

We saw examples of Cloud security use cases at the Cloud service component level in the last section. Let us try to assemble some of these use cases(the attack trees) to detect the illustrative breach (forest) discussed earlier.

WAF: Monitor for SSRF access to http://169.254.169.254/latest/meta-data/iam/security-credentials/ using WAF logs. This is rule match in SIEM

IAM: We should profile “AssumeRole” usage within the environment. This can be done by profiling instance-ID, assumed role, and IP address from Cloud trail logs. If there is a deviation from this profile, there is a high probability that there is a compromise of the credentials. This requires profiling with AI algorithms.

S3 Storage: Profile query for a listing of S3 bucket objects. Any anomalous access from unusual or blacklisted user accounts, IP addresses, and URLs is an indicator of credential compromise and malicious access. This requires profiling using AI algorithms.

S3 Storage: Rule for alerting against any sync or copy of S3 objects from and anomalous or blacklisted user account, IP address, and URL. This is a combination of SIEM rules for threat intel match and profiling using AI algorithms.

WHY IS CLOUD SECURITY DIFFERENT? 08

“ Cloud security monitoring requires a

granular view ofCloud components

leading to aholistic view of

breach in-progress ”

Since this attack, AWS released an updated version2 of instance meta service, making it challenging to execute the query: http://169.254.169.254/latest/meta-data/iam/security-credentials/role-nameagainst metadata. IMDSv2 version requires additional session token information with “HTTP put” to obtain credentials. This protects against using SSRF to compromise credentials to a large extent.

It is clear from the example above that detection of such sophisticated breach scenarios requires an understanding of attack trees that constitute Cloud breaches and detecting these attack trees at the level of Cloud service components. It also requires a combination of SIEM rule matching with AI-based algorithms. It is easy to be lost in the jargons of the Cloud world and live in a false sense of security while monitoring the default events and alerts that show up in the Cloud-native components. Detection of breaches requires more sophisticated capabilities that continuously keep up with the evolving attack scenarios. This, in turn, requires clarity of use cases at component level leading up to the bigger picture needed to detect a breach in progress.

WHY IS CLOUD SECURITY DIFFERENT?09

“ Cloud securitymonitoring requiresa balance betweena granular view of

Cloud components,and a holistic

view of breachesin-progress ”

For more information, please visit http://www.paladion.net.

Paladion is a next-generation cybersecurity provider to technology, manufacturing, and cloud-first companies across the United States. They are consistently recognized and rated by independent technology advisory firms for their Managed Detection and Response Services, Cloud security, and Vulnerability Management & Response services, which is anchored by their patented Artificial Intelligence platform – AIsaac.

ABOUT PALADION

WW Headquarters: 11480 Commerce Park Drive, Suite 210, Reston, VA 20191 USA. Ph: +1-703-956-9468