AWS_CLI_AUTO_PROMPT=on-partial
Having the AWS CLI prompt you for commands https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-prompting.html
Open AWS CLI
export AWS_CLI_AUTO_PROMPT=on-partial
Having the AWS CLI prompt you for commands https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-prompting.html
Open AWS CLI
export AWS_CLI_AUTO_PROMPT=on-partial
Ephemeral AWS Accounts;
Terraform, CloudFormation is for service provision
Ansible is for DevOps automation and configuration management.
This blog is mainly a list of Tools to expose and test entry points into AWS, Azure and GCP. My next goal is to implement these tools and develop some youtube videos. Then after that develop actual detection and mitigation strategies.
👉 Get familiar with Cloud Security fundamentals with Learn to cloud by Gwyneth Peña-Siguenza and Day Johnson
https://lnkd.in/eBn8AJhp
👉 Hacking the cloud by Nick Frichette an encyclopedia of the techniques that offensive security professionals can use against cloud environments.
https://hackingthe.cloud/
👉 Cloud Security – Attacks by Joas A Santos
https://lnkd.in/e5U-KxYj
👉 Practice with this free lab from Pentester Academy
https://lnkd.in/e5n2CZ2f
👉 Practice with Flaws by Scott Piper
https://lnkd.in/eRPsfzC6
👉 Public Cloud Breaches – https://www.breaches.cloud/
👉 Learn AWS Pentesting – https://www.youtube.com/playlist?list=PLMoaZm9nyKaNRN0SoR_PBVYc_RAhbZdG4
💡 Run regular OSINT (Open-Source Intelligence) scans to identify compromised accounts & cycle all credentials based on the accounts found in the OSINT hunt.
💡 Ensuring all accounts have MFA enforced. Accounts without MFA are simply a business risk in today’s era of identity-centric applications & services.
💡 Create conditional access policies to limit access to HVT (High-Value Targets) & HVS (High-Value Services) based on Geo-location, Device/Identity risk, etc.
💡 Create a conditional access policy to limit access to the Azure Portal (Only allow specific group access, enforce MFA, and only allow logins from certain locations) (This not only reduces the Azure Portal attack surface but also enforces the reduced attack surface)
💡 Restrict the Azure AD administration portal.
💡 Enforce strict privilege access on inter-cloud resources such as Subscriptions, Resource Groups & any other Azure workloads.
💡 Enforce strict guest user privileges (ACL) & access (MFA)
💡 Create Sentinel queries & alerts to flag any suspicious activity related to Tenant takeover tactics (Just because the Threat Actor managed to log into the environment (Red Team), does not mean the activity went unnoticed (Blue Team)
AWS – Easy to get started, changes daily, difficult to secure and harder to know if you are “doing it right’. AWS has 1000s of APIs, are you confident there are all secure? Have a good nights sleep.
AWS innovates really quickly. AWS send out a lot of new features that continually change the game in terms of how a central security team can approach security, monitor security, or author their permissions. Keeping up with all of this game-changing information is really, really hard. I follow Twitter and the What’s New announcements for up to date information, and of course the AWS Security Blog; https://twitter.com/awssecurityinfo?lang=en
I passed a number of AWS certs, frankly they were a waste of my time, as they didn’t cover the basics of USING the software. There is no better way to gain experience than hands on software.
Here is some basic by vital bits that should be covered some where, but of course it isn’t very clear.
Firstly, as much as AWS want to advertise they are secure, enabling Logging Monitoring AWS is;
When exec decided to digitally transform into AWS, did they evaluate the cost of talent, AWS isn’t a single product, it is as of this writing 170 products that get upgrade and changed on a daily basis, did you assess this risk. Of course you didn’t. Oh, yeah don’t get me started on the Multi-Cloud stupidity.
You should make sure you get a clear answer from AWS for the following questions;
Essentially, you need to log everything centrally (for investigations and compliance) and Threat detection. What are you logging and what can you detect. You should run a Red Team against this configuration to see what you can detect or not.
In terms of Security Operations perspective the following are the key Use cases required to support your Incident Response Plans;
To establish baseline monitoring, security teams should gather and process the following:
First, there’s the idea of a control plane. The control plane is the master controller (usually in the form of a master node) and includes API services, scheduling capabilities for containers and operational management tools/services. A master-level configuration database is also maintained in the control plane. In general, the control plane can be considered the brains of the Kubernetes infrastructure, and it needs to be very carefully protected.
Focus on the types of events that could be problematic to the environment. Examples include critical assets accessed or changed, identity policies modified, cryptographic keys deleted or changed, and so on.
On top of the Control and Data plane, you need to consider the Access logs for specific AWS Products/Services. In terms of services such as AWS CloudFront, the access logs are not captured via the Control Plan, therefore, you need to capture; Access Logs, Account Activity, and Configuration;
AWS Detective
Billing alarms—If you have a reasonable idea of a monthly billing range, you can break this down to define “checkpoints” that your bill should be at any given time. If these thresholds are crossed, you can be alerted and investigate the reason for the additional cost. Tools like AWS Budgets provide simple alerting and reporting for cloud billing.
Monitor your user activity within the cloud. Admins, in particular, should be monitored carefully, because these accounts are prime targets for attackers. Any nonfederated user access should also be a high priority.
VPC Flow Logs for your VPCs; they are not enabled by default.
AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.
However, AWS Config only collects information about EC2/VPC-related resources, not everything in your AWS account.
You should monitor changes to you AWS real estate and insure all changes are via ITIL Change Management and/or approved automation only.
Firstly, need to understand what AWS services and/or devices are in scope, then map them to your AWS native security logging into ArcSight SmartConnectors.
Click on Resource Groups next to the AWS Services in your aws console page, and select All Regions in region field and All Resources in the resources field. You will get the list of all the resources up and running in your AWS account. You can even tag them separately so you can check how much each resource is costing you.
If there is any other way, for example through AWS CLI, I am curious to know that.
aws resourcegroupstaggingapi get-resources --region region_name
SELECT resourceId, resourceName, resourceType, relationships WHERE relationships.resourceId = 'vpc-#######'
Answer is all of these are complementary and additives services. So let’s example each of them and there primary use cases. So its best to begin with your use cases in terms of SOC operations and Threat Detection;
AWS GuardDuty vs CloudTrail vsSecurityHub vs CloudWatcth acts as an aggregation for other AWS services, which are supported by corresponding ArcSight SmartConnectors. You need to determine where you want to do Threat Detection and hold raw logs for long term retention and investigation.
Here is an overview;
AWS SecurityHub integrates with; https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html
AWS GuardDuty integrates with;
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html
ArcSight SmartConnectors for SecurityHub supports;
https://community.microfocus.com/t5/ArcSight-Connectors/SmartConnector-for-Amazon-Web-Services-Security-Hub/ta-p/2814565
ArcSight SmartConnector supports CloudTrail, S3 and CloudWatch, that maybe ingest logs from AWS native services.
AWS GuardDuty, CloudTrail, SecurityHub and CloudWatcth acts as an aggregation for other AWS services, which are supported by corresponding ArcSight SmartConnectors. AWS (complementary and additive) native Architecture comes into play;
https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs
ArcSight SmartConnector for WiNC (Windows Native Connector) – Recommended for Production Environments
This is where the AWS (complementary and additive) native Architecture comes into play;
IAM Access Analyzer à AWS SecurityHub à ArcSight SmartConnector
You can review the supported data sources here- https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html
AWS IAM Access Analyzer supports ;
ArcSight SmartConnector for AWS SecurityHub support for AWS (complementary and additive) native ArchitectureSo, supported data flow;
You can review the supported data sources here- https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html
AWS GuardDuty, CloudTrail, SecurityHub and CloudWatcth acts as an aggregation for other AWS services, which are supported by corresponding ArcSight SmartConnectors.
AWS SecurityHub integrates with; https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html
AWS GuardDuty integrates with;
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html
ArcSight SmartConnectors for SecurityHub supports;
CloudTrail vs CloudWatch
ArcSight SmartConnector for CloudWatch supports CloudWatch events
ArcSight SmartConnector supports CloudTrail, S3 and CloudWatch, that maybe ingest logs from AWS native logging services.
You need to develop a Threat Model and apply some abuse cases, which is far beyond this blog, so lets just use ATT&CK to identify top risk and develop detection for them.
Attack Phase | TTP |
Initial Access | Discovering valid accounts to AWS account |
Persistence | Creating new accounts |
Defense Evasion | Establishing presences in unused / unsupported cloud regions. Continuing to leverage valid accounts. |
Credential Access | Querying an identify role with a cloud instance’s metadata API. Discovering credentials in files |
Discovery | Cloud service discovery (through network visibility, interaction with other services, and so on.) |
Collection | Data from cloud storage objects (items in S3 buckets, for example.) |
Exfiltration | Outbound data to cloud storage account elsewhere Connectivity to unknown outbound source addresses |
Attack Phase | TTP | AWS Detection |
Initial Access | Discovering valid accounts to cloud environments. | AWS CloudTrail event: Account login via AWS CLI or AWS Management Console (IAM Account.) |
Persistence | Creating new accounts. | AWS CloudTrail event: New IAM account created. |
Defense Evasion | Establishing a presence in unused/unsupported cloud regions. Continuing to leverage valid accounts. | AWS CloudTrail event represented in Amazon GuardDuty or Amazon Detective: New API event in a previously unused region. AWS CloudTrail event represented in Amazon GuardDuty or Amazon Detective: Account use in new region |
Credential Access | Querying an identity role with a cloud instance’s metadata API. Discovery credentials in files. | AWS CloudTrail event represented in Amazon GuardDuty, third- party SIEM or Amazon Detective: Metadata service queried for new services and role permissions AWS CloudTrail event: Account login via AWS CLI or AWS Management Console. |
Discovery | Cloud services discovery (through network visibility, interaction with other services, and so on.) System information discovery. System network connection discovery. | |
Collection | Data from cloud storage objects (items in S3 buckets, for example.) Data from local systems | |
Exfiltration | Outbound data to a cloud storage account elsewhere. |
“eventTime”: “2017-01-20T18:53:02Z”, “eventSource”: “iam.amazonaws.com”, “eventName”: “DeactivateMFADevice”, “awsRegion”: “us-east-1”, “sourceIPAddress”: “1.2.3.4”, “userAgent”: “signin.amazonaws.com”, “requestParameters”: {
“userName”: “dave”,
“serialNumber”: “arn:aws:iam::000012345678:mfa/dave” },
“responseElements”: null,
“requestID”: “d1a9ebf8-5fc8-11e5-9d8f-1bc7c6757e61”,
Suspicious AWS CloudTrail event that
indicates a cloud user trying to deactivate
an MFA device.
How to Improve Security Visibility and Detection/Response Operations in AWS
How to Improve Security Visibility and Detection/Response Operations in AWS
Priority 1
– Launching a workload that is not from an approved template
– Launching any containers from unapproved images in a repository
– Launching any assets in unapproved regions
– Modifying any IAM roles or policies
– Modifying or disabling cloud control plane logging or other security controls – Logins to the web console (unauthorized)
• Priority 2
– Unusual user behaviors (trying to access unauthorized resources, etc.) – Adding/updating new workload images
– Adding/updating new container images
– Logins to the web console (authorized)
– Updating/changing serverless configuration
• Priority 3
– Changes to security groups or network access control lists (ACLs) – Updating/changing serverless function code
How to Improve Security Visibility and Detection/Response Operations in AWS
able 1. Starting Points for Event Searches
AWS CloudTrail Event | Reason for Investigation |
ConsoleLogin | A user initiates console login activity. |
StopLogging | A user tries to stop AWS CloudTrail. |
CreateNetworkAclEntry | Someone creates a network ACL, which could expose attack surfaces or vectors. |
CreateRoute | Someone creates a new route for data path control, which could expose attack surfaces or vectors. |
AuthorizeSecurityGroupEgress AuthorizeSecurityGroupIngress RevokeSecurityGroupEgress RevokeSecurityGroupIngress | Monitor all changes to security groups. |
ApplySecurityGroupsToLoadBalancer SetSecurityGroups | Security group changes that tie to elastic load balancers are interesting, often in scaling operations. This may indicate unusual traffic surges in the environment. |
AuthorizeDBSecurityGroupIngress CreateDBSecurityGroup DeleteDBSecurityGroup RevokeDBSecurityGroupIngress | Amazon RDS instances have a different nomenclature for security groups, but are the same thing conceptually. Security teams should monitor such instances. |
How to Improve Security Visibility and Detection/Response Operations in AWS
AWS Lambda Event | Reason for Monitoring |
DeleteEventSourceMapping | Someone could delete the data source that triggers an AWS Lambda function, making it “blind.” |
DeleteFunction | A function could be deleted purposefully or accidentally, leading to security issues. |
RemovePermission | This could lead to a lockout scenario or lack of access when needed (think IAM service account or role access to AWS Lambda). |
UpdateEventSourceMapping | Data could be pulled from a different source, leading to incorrect function results. |
UpdateFunctionCode | The function could be broken or tampered with to prevent security-specific functionality from executing (for example, by adding comments). |
UpdateFunctionConfiguration | The configuration of the function could be changed to limit its resources, causing poor or flawed execution. |
Capability | AWS Services | Digital Forencics |
Compute | Amazon Elastic Cloud Compute (EC2) | Uses Amazon Machine Images (AMIs) to get started Multiple OS support Pay for what you use Next-gen Nitro infrastructure, created by AWS |
Storage | Amazon Elastic Block Store (EBS), Amazon Simple Storage Service (S3), Amazon Elastic File System (EFS) | Amazon S3 offers multiple storage classes for multiple use cases. Amazon EBS is used for the “block device” or hard drive for Amazon EC2 instances. Amazon EFS is used for file sharing storage with two storage classes to choose from. |
NetFlow | Amazon VPC Flow Logs, Amazon VPC Traffic Mirroring | Capture information of network traffic going in and out of a VPC |
Auditing | AWS CloudTrail | User attribution data Log integrity can be enabled Can send data to an Amazon S3 bucket for storage/archival |
Digital Forensic Analysis of Amazon Linux EC2 Instances; https://www.sans.org/reading-room/whitepapers/cloud/digital-forensic-analysis-amazon-linux-ec2-instances-38235
How to Perform a Security Investigation in AWS A SANS Whitepaper
https://aws.amazon.com/blogs/aws/new-vpc-traffic-mirroring/
How to Improve Security Visibility and Detection/Response Operations in AWS
How to Improve Security Visibility and Detection/Response Operations in AWS
CREATE EXTERNAL TABLE cloudtrail_logs (
eventversion STRING,
useridentity STRUCT<
type:STRING,
principalid:STRING,
arn:STRING,
accountid:STRING,
invokedby:STRING,
accesskeyid:STRING,
userName:STRING,
sessioncontext:STRUCT<
attributes:STRUCT<
mfaauthenticated:STRING,
creationdate:STRING>,
sessionissuer:STRUCT<
type:STRING,
principalId:STRING,
arn:STRING,
accountId:STRING,
userName:STRING>>>,
eventtime STRING,
eventsource STRING,
eventname STRING,
awsregion STRING,
sourceipaddress STRING,
useragent STRING,
errorcode STRING,
errormessage STRING,
requestparameters STRING,
responseelements STRING,
additionaleventdata STRING,
requestid STRING,
eventid STRING,
resources ARRAY<STRUCT<
ARN:STRING,
accountId:STRING,
type:STRING>>,
eventtype STRING,
apiversion STRING,
readonly STRING,
recipientaccountid STRING,
serviceeventdetails STRING,
sharedeventid STRING,
vpcendpointid STRING
)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://mycloudtrailbucket-faye/AWSLogs/757250003982/';
SELECT
useridentity.arn,
eventname,
sourceipaddress,
eventtime
FROM cloudtrail_logs
LIMIT 100;
GetLogEvents support 10 requests per second per account per Region
· Each request has a limit of 1MB to 10000MB(10GB)
· 1MB equals around 10,000 log events, so upto 100million log events per request.
· Hence, with 10 requests per second it will capture upto 1 trillion log events per second.
– https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html
– https://docs.aws.amazon.com/cli/latest/reference/logs/get-log-events.html#examples
– https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-logs-retrieve-data/
– https://github.com/awsdocs/amazon-cloudwatch-logs-user-guide/blob/master/doc_source/cloudwatch_limits_cwl.md
https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogEvents.html
GetLogEvents 10 requests per second per account per Region. This limit cannot be changed. We recommend subscriptions if you are continuously processing new data. If you need historical data, we recommend exporting your data to Amazon S3.
Classify your data into sensitivity levels and where appropriate, use mechanisms like encryption and access control.
https://scaling-threat-detection.awssecworkshops.com/#architecture