{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/eks/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Agent Auditd Manager","EKS","Azure","gcloud","Docker"],"_cs_severities":["high"],"_cs_tags":["credential-access","linux","auditd"],"_cs_type":"advisory","_cs_vendors":["Elastic","Amazon","Microsoft","Google","Docker"],"content_html":"\u003cp\u003eThis detection focuses on identifying unauthorized access to sensitive identity files on Linux systems. It leverages Auditd to monitor file access events and flags processes that are commonly used for copying, scripting, or staging files from temporary directories. The targeted files include Kubernetes service account tokens, kubelet configurations, cloud CLI configurations for AWS, Azure, and Google Cloud, root SSH keys, and Docker configurations. These files are critical for authentication and authorization within the system, and unauthorized access could lead to credential theft, privilege escalation, or lateral movement. This is especially important in cloud environments and containerized deployments where these files are commonly used for managing access to resources. The rule is designed to exclude user home paths to avoid false positives and focus on system-level access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a utility like \u003ccode\u003ecp\u003c/code\u003e, \u003ccode\u003ecat\u003c/code\u003e, or \u003ccode\u003ecurl\u003c/code\u003e to access sensitive files such as \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e or \u003ccode\u003e/root/.ssh/id_rsa\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAuditd logs the file access event, capturing details about the process, user, and file path.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies the suspicious process based on its name, executable path (e.g., \u003ccode\u003e/tmp/*\u003c/code\u003e), or command-line arguments.\u003c/li\u003e\n\u003cli\u003eThe rule checks if the accessed file is in the list of sensitive identity files.\u003c/li\u003e\n\u003cli\u003eIf both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen credentials or uses them to move laterally within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access cloud resources or other sensitive systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (\u003ccode\u003eauditctl -l\u003c/code\u003e) to generate the necessary logs.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.\u003c/li\u003e\n\u003cli\u003eReview and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-sensitive-identity-file-access/","summary":"This rule detects suspicious processes, such as copy utilities or scripting tools, accessing sensitive identity files on Linux systems, including Kubernetes tokens, cloud CLI configurations, and root SSH keys, indicating potential credential theft.","title":"Suspicious Process Accessing Sensitive Identity Files via Auditd","url":"https://feed.craftedsignal.io/briefs/2024-01-sensitive-identity-file-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EKS","STS"],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","iam","kubernetes","initial-access","web-identity"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies instances of successful AWS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the service account token from the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to call the AWS STS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e call is made from a network with an ASN organization name that is not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e event, including details about the user, source IP, and ASN organization.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM role is used to perform unauthorized actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThese actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by following the investigation steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eExpand the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions in the Sigma rule for known and trusted egress paths if needed.\u003c/li\u003e\n\u003cli\u003eEnable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls.\u003c/li\u003e\n\u003cli\u003eRegularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.\u003c/li\u003e\n\u003cli\u003eRevoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-aws-assume-role-external-asn/","summary":"Detects successful AWS `AssumeRoleWithWebIdentity` calls where the caller identity is a Kubernetes service account and the source autonomous system organization is not `Amazon.com, Inc.`, which may indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.","title":"AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-assume-role-external-asn/"}],"language":"en","title":"CraftedSignal Threat Feed — EKS","version":"https://jsonfeed.org/version/1.1"}