{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/privilegeescalation/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Azure Active Directory"],"_cs_severities":["critical"],"_cs_tags":["azuread","cloud","graphapi","privilegeescalation","persistence"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on the assignment of privileged Graph API permissions within Azure Active Directory (Azure AD). Attackers, including groups like NOBELIUM, may attempt to assign themselves or compromised applications excessive permissions to maintain persistence, escalate privileges, or achieve other malicious objectives within the cloud environment. The permissions of concern are Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory, as these grant broad control over applications, role assignments, and directory settings. The detection leverages Azure AD audit logs specifically monitoring 'Update application' operations. Successful exploitation can lead to unauthorized modifications and potential security breaches, compromising the integrity and security of the Azure AD environment. This activity became particularly relevant after the Midnight Blizzard attack, highlighting the need for robust monitoring of Azure AD permission changes.\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 AD account, possibly through credential theft or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses the Azure CLI with the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies an existing application registration within Azure AD that they can modify.\u003c/li\u003e\n\u003cli\u003eUsing the compromised account, the attacker attempts to update the application registration.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns one or more of the following high-risk Graph API permissions to the application: Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, or RoleManagement.ReadWrite.Directory. This involves modifying the \u003ccode\u003erequiredAppPermissions\u003c/code\u003e property of the application object.\u003c/li\u003e\n\u003cli\u003eThe Azure AD audit log records an \u0026quot;Update application\u0026quot; event with the modified \u003ccode\u003erequiredAppPermissions\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the application's newly acquired permissions to perform malicious actions, such as reading or modifying application configurations, role assignments, or directory settings.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by leveraging the application's elevated privileges for ongoing unauthorized access and control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful assignment of these permissions can lead to a complete compromise of the Azure AD environment. An attacker can modify application configurations, create or delete users, assign roles, and potentially gain access to other connected resources and services. The impact can range from data breaches and service disruption to complete control over the organization's cloud identity infrastructure. This is a critical issue, especially in light of recent nation-state attacks targeting Azure AD, as highlighted by Microsoft's guidance on the Midnight Blizzard attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eAzure AD Privileged Graph API Permission Assigned\u003c/code\u003e to your SIEM, ensuring it is tuned to your environment, and enable the data source: \u003ccode\u003eazure_monitor_aad\u003c/code\u003e with category \u003ccode\u003eAuditLogs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule \u003ccode\u003eAzure AD Privileged Graph API Permission Assigned\u003c/code\u003e immediately to determine if the permission assignment was authorized.\u003c/li\u003e\n\u003cli\u003eReview application registrations in Azure AD and identify any applications with excessive or unnecessary permissions.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for any modifications to application registrations, focusing on changes to the \u003ccode\u003erequiredAppPermissions\u003c/code\u003e property.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of credential theft.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-azure-ad-graph-permissions/","summary":"Detection of high-risk Graph API permission assignments (Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory) in Azure AD, potentially leading to unauthorized modifications and security breaches.","title":"Azure AD Privileged Graph API Permission Assignment","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-ad-graph-permissions/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","hostnetwork","privilegeescalation"],"_cs_type":"advisory","_cs_vendors":["Kubernetes"],"content_html":"\u003cp\u003eThis alert identifies the creation or update of a Kubernetes pod configured to use the host network namespace. Kubernetes audit logs are analyzed to detect pods with the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting. This configuration allows a pod to share the network stack of the host node, effectively granting it access to all network interfaces and traffic. This presents a significant security risk, especially if the pod is compromised. An attacker can then monitor all network traffic on the node, potentially capturing sensitive information such as credentials or API keys, and potentially escalating privileges to gain control over the node and the entire cluster. This detection is critical for SOC teams to identify and investigate potentially malicious activity within their Kubernetes 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 the Kubernetes cluster, potentially through compromised credentials, a vulnerable application, or a misconfigured service.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious pod specification that includes the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting. This setting is included within the \u003ccode\u003erequestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create or update a pod using the crafted specification, submitting the request to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server logs the pod creation or update request in the audit logs, including details about the pod's configuration and the user who initiated the request.\u003c/li\u003e\n\u003cli\u003eThe detection logic identifies the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting in the audit logs, triggering the alert.\u003c/li\u003e\n\u003cli\u003eAn attacker leverages access to the host network to sniff network traffic, intercepting sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses captured credentials or other sensitive information to escalate privileges within the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging a pod with host network attachment can have severe consequences. An attacker could gain complete control over the compromised node, potentially leading to data breaches, service disruptions, and unauthorized access to sensitive resources. Furthermore, the attacker could use the compromised node as a launchpad for further attacks within the cluster, compromising other pods and services. This can lead to a full cluster compromise with significant damage and data loss.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Kubernetes audit logging and configure the audit policy to capture pod creation and update events. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs as described in the documentation \u003ca href=\"https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md\"\u003ehttps://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Pod with Host Network Attachment\u003c/code\u003e to your SIEM to detect the creation or update of pods with the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule to determine the legitimacy of the pod creation/update and the user who initiated the request.\u003c/li\u003e\n\u003cli\u003eMonitor the users and source IPs identified in the detection (\u003ccode\u003euser\u003c/code\u003e, \u003ccode\u003esrc_ip\u003c/code\u003e) for other suspicious activities within the cluster.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/","summary":"Detection of Kubernetes pods configured to use the host network namespace via audit logs, potentially allowing attackers to monitor all node network traffic for sensitive data and privilege escalation.","title":"Kubernetes Pod with Host Network Attachment Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/"}],"language":"en","title":"CraftedSignal Threat Feed - Privilegeescalation","version":"https://jsonfeed.org/version/1.1"}