Privilegeescalation - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/privilegeescalation/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioMon, 29 Jan 2024 12:00:00 +0000Azure AD Privileged Graph API Permission Assignmenthttps://feed.craftedsignal.io/briefs/2024-01-azure-ad-graph-permissions/Mon, 29 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-azure-ad-graph-permissions/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.This 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.

Attack Chain

  1. An attacker gains initial access to an Azure AD account, possibly through credential theft or phishing.
  2. The attacker authenticates to the Azure portal or uses the Azure CLI with the compromised account.
  3. The attacker identifies an existing application registration within Azure AD that they can modify.
  4. Using the compromised account, the attacker attempts to update the application registration.
  5. The 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 requiredAppPermissions property of the application object.
  6. The Azure AD audit log records an "Update application" event with the modified requiredAppPermissions.
  7. The attacker uses the application's newly acquired permissions to perform malicious actions, such as reading or modifying application configurations, role assignments, or directory settings.
  8. The attacker maintains persistence by leveraging the application's elevated privileges for ongoing unauthorized access and control.

Impact

Successful 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.

Recommendation

  • Deploy the provided Sigma rule Azure AD Privileged Graph API Permission Assigned to your SIEM, ensuring it is tuned to your environment, and enable the data source: azure_monitor_aad with category AuditLogs.
  • Investigate any alerts triggered by the Sigma rule Azure AD Privileged Graph API Permission Assigned immediately to determine if the permission assignment was authorized.
  • Review application registrations in Azure AD and identify any applications with excessive or unnecessary permissions.
  • Monitor Azure AD audit logs for any modifications to application registrations, focusing on changes to the requiredAppPermissions property.
  • Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of credential theft.
]]>criticalthreatazureadcloudgraphapiprivilegeescalationpersistenceKubernetes Pod with Host Network Attachment Detectedhttps://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/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.This 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 hostNetwork: true 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.

Attack Chain

  1. An attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials, a vulnerable application, or a misconfigured service.
  2. The attacker crafts a malicious pod specification that includes the hostNetwork: true setting. This setting is included within the requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration field.
  3. The attacker attempts to create or update a pod using the crafted specification, submitting the request to the Kubernetes API server.
  4. The 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.
  5. The detection logic identifies the hostNetwork: true setting in the audit logs, triggering the alert.
  6. An attacker leverages access to the host network to sniff network traffic, intercepting sensitive data.
  7. The attacker uses captured credentials or other sensitive information to escalate privileges within the cluster.

Impact

A 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.

Recommendation

  • Enable 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 https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
  • Deploy the Sigma rule Kubernetes Pod with Host Network Attachment to your SIEM to detect the creation or update of pods with the hostNetwork: true setting.
  • Investigate any alerts generated by this rule to determine the legitimacy of the pod creation/update and the user who initiated the request.
  • Monitor the users and source IPs identified in the detection (user, src_ip) for other suspicious activities within the cluster.
]]>highadvisorykuberneteshostnetworkprivilegeescalation