NOBELIUM Group - CraftedSignal Threat Feed

Azure AD Privileged Graph API Permission Assignment

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

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

An attacker gains initial access to an Azure AD account, possibly through credential theft or phishing.
The attacker authenticates to the Azure portal or uses the Azure CLI with the compromised account.
The attacker identifies an existing application registration within Azure AD that they can modify.
Using the compromised account, the attacker attempts to update the application registration.
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.
The Azure AD audit log records an "Update application" event with the modified requiredAppPermissions.
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.
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.

Azure AD FullAccessAsApp Permission Assignment

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

This threat brief focuses on the detection of the 'full_access_as_app' permission being assigned to an application within Office 365 Exchange Online. This activity is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. The observed activity leverages the "Update application" operation in Azure Active Directory AuditLogs. The threat is significant because successful exploitation grants the attacker the ability to impersonate any user within the targeted organization, leading to potential data breaches, financial fraud, or further compromise of the environment. References to Microsoft's response to the Midnight Blizzard campaign indicate that this type of permission abuse has been seen in nation-state attacks.

Attack Chain

The attacker compromises an Azure AD account with sufficient privileges.
The attacker uses the compromised account to access the Azure portal or uses PowerShell/Graph API.
The attacker registers a malicious application within the Azure AD tenant, or modifies an existing one.
The attacker assigns the 'full_access_as_app' permission (dc890d15-9560-4a4c-9b7f-a736ec74ec40) to the application. This is achieved through the "Update application" operation.
The application gains full access to all mailboxes in the Exchange Online environment (ResourceAppId: 00000002-0000-0ff1-ce00-000000000000).
The attacker leverages the granted permissions to access sensitive emails, contacts, and calendar data from targeted mailboxes.
The attacker may send emails on behalf of other users, potentially leading to phishing attacks or business email compromise (BEC).
The attacker exfiltrates sensitive data or maintains persistence within the environment by creating new rogue applications.

Impact

Successful assignment of the 'full_access_as_app' permission allows an attacker to access and control all mailboxes within the targeted Office 365 Exchange Online environment. This can lead to significant data breaches, financial losses through BEC attacks, and reputational damage. Organizations in any sector are vulnerable, but those handling sensitive data or operating in regulated industries face the highest risk. Nation-state actors like NOBELIUM have been known to exploit this type of permission abuse to gain long-term access to victim networks.

Recommendation

Deploy the Sigma rule "Azure AD FullAccessAsApp Permission Assigned" to your SIEM and tune for your environment to detect unauthorized assignments of the 'full_access_as_app' permission.
Review Azure AD audit logs for "Update application" events where the 'full_access_as_app' permission (dc890d15-9560-4a4c-9b7f-a736ec74ec40) is being assigned.
Implement the recommendations from Microsoft's blog post "Midnight Blizzard Guidance for Responders on Nation State Attack" to harden your Azure AD environment and prevent similar attacks.
Monitor for applications with excessive permissions, especially those with the 'full_access_as_app' permission, and investigate any anomalies.
Regularly audit application permissions in Azure AD to identify and remediate any overly permissive configurations.

O365 Service Principal Creation Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This threat brief focuses on the detection of newly created service principal accounts within Microsoft Office 365 environments. The creation of service principals is a legitimate administrative function, but malicious actors can exploit them to gain persistent access to cloud resources. Attackers, like the NOBELIUM group, can use compromised or maliciously created service principals to interact with APIs, access sensitive data, and perform unauthorized operations on behalf of the organization. These actions can lead to significant data breaches, lateral movement, and further compromise of the O365 tenant. This activity is often associated with advanced persistent threat (APT) groups targeting cloud environments for long-term access and data exfiltration. The detection strategy leverages O365 management activity logs to identify suspicious creation events, allowing for proactive investigation and mitigation of potential threats.

Attack Chain

Initial Access: Attacker gains initial access to an O365 account, possibly through phishing or credential stuffing (not directly observed in the provided data, but a common precursor).
Privilege Escalation: The attacker escalates privileges within the compromised account to allow for the creation of service principals.
Service Principal Creation: A new service principal is created within the Azure Active Directory, using commands or API calls. The creation event is logged within the O365 management activity logs.
Permissions Assignment: The attacker assigns the newly created service principal with elevated permissions, granting access to critical resources within the O365 environment.
API Access: The attacker leverages the service principal to interact with Microsoft Graph API or other O365 APIs, bypassing standard user authentication mechanisms.
Data Exfiltration: The attacker utilizes the API access to exfiltrate sensitive data from various O365 services, such as SharePoint, OneDrive, or Exchange Online.
Persistence: The service principal acts as a persistent backdoor, allowing the attacker to regain access to the environment even if the initial compromised account is remediated.

Impact

A successful attack involving a rogue service principal can lead to significant data breaches, with potential exposure of sensitive corporate data, customer information, and intellectual property. The number of victims depends on the permissions assigned to the malicious service principal and the scope of data accessible within the O365 environment. Affected sectors include any organization relying on O365 for business operations, but especially those with sensitive data like finance, healthcare, and government. If the attack succeeds, organizations face reputational damage, financial losses, legal liabilities, and operational disruption.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune them to reduce false positives based on your organization's normal service principal creation activity (rules).
Investigate any alerts generated by the Sigma rules, focusing on the user accounts responsible for creating the service principals and the permissions assigned to them (rules).
Enable and review O365 Management Activity logs to ensure comprehensive monitoring of service principal creation and modification events (data_source).
Implement multi-factor authentication (MFA) for all user accounts, including administrative accounts, to mitigate the risk of initial access through compromised credentials (T1136.003).
Review and enforce the principle of least privilege for service principals, limiting their access to only the resources they require (T1136.003).
Monitor for anomalous API usage patterns associated with service principals, such as unusual data access or exfiltration activities (T1136.003).

O365 ApplicationImpersonation Role Assigned

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The ApplicationImpersonation role in Office 365 grants extensive privileges, allowing a user or application to impersonate any other user within the organization. Assignment of this role is a sensitive event that requires careful monitoring. This activity is significant because the ApplicationImpersonation role allows impersonation of any user, enabling access to and modification of their mailbox. Attackers, such as the NOBELIUM group, can abuse this role to gain unauthorized access to sensitive information, manipulate mailbox data, and perform actions as a legitimate user. The source detection logic leverages the Office 365 Management Activity API to monitor Azure Active Directory audit logs.

Attack Chain

Initial Access: An attacker gains initial access to an account with sufficient privileges to modify Office 365 roles.
Privilege Escalation: The attacker attempts to assign the ApplicationImpersonation role to a compromised user account or a newly created service principal. This can be achieved via PowerShell or the Azure AD portal.
Role Assignment: The "New-ManagementRoleAssignment" operation is executed within the Office 365 environment, assigning the ApplicationImpersonation role.
Persistence: The attacker leverages the newly assigned ApplicationImpersonation role to maintain persistent access to the target organization's mailboxes.
Data Access: The attacker uses the ApplicationImpersonation role to access and exfiltrate sensitive data from mailboxes.
Lateral Movement: With access to user mailboxes, the attacker gathers information to facilitate lateral movement within the organization.
Covering Tracks: The attacker may attempt to disable logging or remove audit trails to conceal their activities.

Impact

Successful exploitation can lead to complete compromise of sensitive email data, intellectual property theft, and potential business email compromise (BEC) attacks. An attacker with the ApplicationImpersonation role can read, modify, and delete emails from any user's mailbox, leading to significant data breaches and reputational damage.

Recommendation

Deploy the Sigma rule O365 ApplicationImpersonation Role Assigned to your SIEM and tune for your environment.
Review existing ApplicationImpersonation role assignments to identify and revoke any unauthorized or suspicious grants.
Monitor O365 management activity logs for unusual "New-ManagementRoleAssignment" events.
Investigate any alerts triggered by the detection logic, focusing on the target_user and user fields in the logs.
Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges.
Regularly audit Azure AD roles and permissions to ensure least privilege.

O365 Application Registration Owner Added

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The addition of a new owner to an application registration in Azure AD and Office 365 tenants is a notable security event. Attackers may target application registrations to gain persistence or elevate privileges within an organization. The Splunk ES content published on 2026-04-17 detects this activity by monitoring O365 audit logs for events related to changes in owner assignments within the AzureActiveDirectory workload. This technique can be used by threat actors like NOBELIUM to establish persistence mechanisms within compromised environments. Successfully adding a malicious owner to an application registration can allow the attacker to modify application settings, permissions, and behavior, leading to unauthorized data access, privilege escalation, or the introduction of malicious behavior within the application's operations.

Attack Chain

The attacker gains initial access to a compromised user account, potentially through phishing or credential stuffing.
The attacker logs into the Azure portal using the compromised account.
The attacker navigates to the Azure Active Directory section.
The attacker identifies a target application registration to compromise.
The attacker uses the compromised account to add a new owner to the application registration via the Azure portal or PowerShell cmdlets.
The attacker configures the compromised application registration with malicious settings or permissions.
The attacker uses the compromised application registration to gain unauthorized access to data or resources.
The attacker leverages the compromised application registration for persistence within the environment.

Impact

Successful exploitation of this technique can allow attackers to establish persistence within the compromised environment, escalate privileges, and gain unauthorized access to sensitive data. This can lead to data breaches, financial loss, and reputational damage. The number of affected users and the scope of the damage will vary depending on the permissions and configurations of the compromised application registration.

Recommendation

Deploy the Sigma rule "O365 Application Registration Owner Added" to your SIEM and tune for your environment.
Enable O365 management activity logging to ensure the necessary events are captured (data_source: "O365 Add owner to application.").
Review and monitor application registration owner assignments for any suspicious or unauthorized changes (references: "https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/overview-assign-app-owners").
Investigate any alerts triggered by the Sigma rule, focusing on the user and object involved (rule: "O365 Application Registration Owner Added").

Azure AD Tenant Wide Admin Consent Granted

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category, and utilizes the azure:monitor:aad sourcetype. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. The detection is sourced from Splunk's ES Content and adapted for broader use. Successfully gaining admin consent can grant attackers persistent access and control over the Azure AD environment.

Attack Chain

An attacker compromises an administrator account through phishing or credential stuffing.
The attacker logs into the Azure portal using the compromised administrator credentials.
The attacker navigates to the Azure Active Directory section.
The attacker registers a malicious application or uses an existing compromised application.
The attacker requests tenant-wide admin consent for the malicious application. This often involves tricking the administrator into approving the request.
The administrator grants consent, either unknowingly or due to social engineering.
The malicious application gains access to data across the entire tenant based on the granted permissions.
The attacker uses the application's permissions to exfiltrate sensitive data, establish persistence, or perform other malicious actions.

Impact

Successful exploitation allows attackers to gain extensive and persistent access to sensitive data within the Azure AD tenant. This can lead to data exfiltration, espionage, further malicious activities, and potential compliance violations. The impact spans across all applications and data within the tenant that the application has been granted access to. Lateral movement becomes trivial, and the attacker can establish a strong foothold within the cloud environment.

Recommendation

Deploy the Sigma rule "Azure AD Tenant Wide Admin Consent Granted" to your SIEM and tune for your environment.
Investigate any instances of admin consent being granted, especially if the application is unfamiliar or the request seems suspicious. Reference the detection results by using the provided drilldown searches.
Implement multi-factor authentication (MFA) for all administrator accounts to mitigate the risk of compromised credentials.
Regularly review and audit application permissions within Azure AD to identify and remove any unnecessary or overly permissive consents.
Monitor Azure AD audit logs for unusual activity, such as unexpected application registrations or consent requests. Enable azure:monitor:aad sourcetype and Auditlogs log category.

Azure AD Service Principal Owner Added

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This analytic detects the addition of a new owner to a Service Principal within an Azure AD tenant. Service Principals are often targeted by attackers due to their lack of multi-factor authentication (MFA) and conditional access support. The detection leverages Azure Active Directory events from the AuditLog log category, specifically monitoring the "Add owner to application" operation. This activity is a significant indicator of potential persistence or privilege escalation, as a compromised Service Principal can grant unauthorized access to critical Azure AD resources. A successful attack using this technique could allow attackers to maintain access to the Azure AD environment with only single-factor authentication, bypassing typical security controls. This detection is based on analysis of activity patterns associated with the NOBELIUM group.

Attack Chain

The attacker compromises an initial user account or service principal through credential theft or other means (e.g., phishing).
The attacker leverages the compromised account to enumerate existing Service Principals within the Azure AD tenant.
The attacker identifies a target Service Principal with elevated permissions or access to critical resources.
The attacker executes the "Add owner to application" operation, adding a new owner (controlled by the attacker) to the target Service Principal. This operation is logged in Azure AD Audit Logs.
The newly added owner account (controlled by the attacker) now has control over the Service Principal.
The attacker uses the compromised Service Principal to access resources and data within the Azure AD environment, bypassing MFA and conditional access controls.
The attacker moves laterally within the cloud environment, compromising other services and resources.
The attacker achieves their final objective, which may include data exfiltration, system disruption, or further privilege escalation.

Impact

A successful attack leveraging Service Principal owner addition can result in significant damage. Attackers can gain persistent access to the Azure AD environment, bypassing MFA and conditional access. This can lead to unauthorized access to sensitive data, compromise of critical cloud resources, and potential disruption of business operations. Due to the nature of cloud environments, a single compromised Service Principal can grant access to a wide range of services and data, impacting numerous users and applications.

Recommendation

Deploy the Sigma rule Azure AD Service Principal Owner Added to your SIEM and tune for your environment to detect the addition of new owners to Service Principals based on Azure AD Audit Logs.
Investigate any detected instances of Service Principal owner additions for potentially malicious activity, focusing on the initiatedBy and newOwner fields in the logs.
Implement strict controls and monitoring around Service Principal creation and management.
Review and reduce the number of Service Principals with excessive privileges.
Investigate related Azure Active Directory Persistence and Azure Active Directory Privilege Escalation analytic stories after detecting this activity.