{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/actors/nobelium-group/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":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Office 365 Exchange Online","Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","azuread","office365","persistence","nobelium"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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 \u0026quot;Update application\u0026quot; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises an Azure AD account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised account to access the Azure portal or uses PowerShell/Graph API.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a malicious application within the Azure AD tenant, or modifies an existing one.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the 'full_access_as_app' permission (dc890d15-9560-4a4c-9b7f-a736ec74ec40) to the application. This is achieved through the \u0026quot;Update application\u0026quot; operation.\u003c/li\u003e\n\u003cli\u003eThe application gains full access to all mailboxes in the Exchange Online environment (ResourceAppId: 00000002-0000-0ff1-ce00-000000000000).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the granted permissions to access sensitive emails, contacts, and calendar data from targeted mailboxes.\u003c/li\u003e\n\u003cli\u003eThe attacker may send emails on behalf of other users, potentially leading to phishing attacks or business email compromise (BEC).\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or maintains persistence within the environment by creating new rogue applications.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Azure AD FullAccessAsApp Permission Assigned\u0026quot; to your SIEM and tune for your environment to detect unauthorized assignments of the 'full_access_as_app' permission.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for \u0026quot;Update application\u0026quot; events where the 'full_access_as_app' permission (dc890d15-9560-4a4c-9b7f-a736ec74ec40) is being assigned.\u003c/li\u003e\n\u003cli\u003eImplement the recommendations from Microsoft's blog post \u0026quot;Midnight Blizzard Guidance for Responders on Nation State Attack\u0026quot; to harden your Azure AD environment and prevent similar attacks.\u003c/li\u003e\n\u003cli\u003eMonitor for applications with excessive permissions, especially those with the 'full_access_as_app' permission, and investigate any anomalies.\u003c/li\u003e\n\u003cli\u003eRegularly audit application permissions in Azure AD to identify and remediate any overly permissive configurations.\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-azuread-fullaccess/","summary":"Detection of 'full_access_as_app' permission assignment to an application in Office 365 Exchange Online, potentially leading to unauthorized access and data exfiltration.","title":"Azure AD FullAccessAsApp Permission Assignment","url":"https://feed.craftedsignal.io/briefs/2024-01-azuread-fullaccess/"},{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Office 365","Azure Active Directory","Microsoft Graph API","SharePoint","OneDrive","Exchange Online"],"_cs_severities":["high"],"_cs_tags":["cloud","o365","service_principal","persistence","azuread"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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.\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 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).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates privileges within the compromised account to allow for the creation of service principals.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Creation:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePermissions Assignment:\u003c/strong\u003e The attacker assigns the newly created service principal with elevated permissions, granting access to critical resources within the O365 environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAPI Access:\u003c/strong\u003e The attacker leverages the service principal to interact with Microsoft Graph API or other O365 APIs, bypassing standard user authentication mechanisms.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker utilizes the API access to exfiltrate sensitive data from various O365 services, such as SharePoint, OneDrive, or Exchange Online.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune them to reduce false positives based on your organization's normal service principal creation activity (\u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on the user accounts responsible for creating the service principals and the permissions assigned to them (\u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable and review O365 Management Activity logs to ensure comprehensive monitoring of service principal creation and modification events (\u003ccode\u003edata_source\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, including administrative accounts, to mitigate the risk of initial access through compromised credentials (T1136.003).\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for service principals, limiting their access to only the resources they require (T1136.003).\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous API usage patterns associated with service principals, such as unusual data access or exfiltration activities (T1136.003).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/","summary":"Detection of new service principal creation in O365 tenants, which can be abused by attackers for unauthorized access, API interaction, and data compromise.","title":"O365 Service Principal Creation Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/"},{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Microsoft 365","Azure Active Directory"],"_cs_severities":["critical"],"_cs_tags":["cloud","o365","applicationimpersonation","persistence"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains initial access to an account with sufficient privileges to modify Office 365 roles.\u003c/li\u003e\n\u003cli\u003ePrivilege 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.\u003c/li\u003e\n\u003cli\u003eRole Assignment: The \u0026quot;New-ManagementRoleAssignment\u0026quot; operation is executed within the Office 365 environment, assigning the ApplicationImpersonation role.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker leverages the newly assigned ApplicationImpersonation role to maintain persistent access to the target organization's mailboxes.\u003c/li\u003e\n\u003cli\u003eData Access: The attacker uses the ApplicationImpersonation role to access and exfiltrate sensitive data from mailboxes.\u003c/li\u003e\n\u003cli\u003eLateral Movement: With access to user mailboxes, the attacker gathers information to facilitate lateral movement within the organization.\u003c/li\u003e\n\u003cli\u003eCovering Tracks: The attacker may attempt to disable logging or remove audit trails to conceal their activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eO365 ApplicationImpersonation Role Assigned\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview existing ApplicationImpersonation role assignments to identify and revoke any unauthorized or suspicious grants.\u003c/li\u003e\n\u003cli\u003eMonitor O365 management activity logs for unusual \u0026quot;New-ManagementRoleAssignment\u0026quot; events.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the detection logic, focusing on the \u003ccode\u003etarget_user\u003c/code\u003e and \u003ccode\u003euser\u003c/code\u003e fields in the logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eRegularly audit Azure AD roles and permissions to ensure least privilege.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-app-impersonation/","summary":"Detection of the ApplicationImpersonation role being assigned in Office 365, potentially leading to unauthorized mailbox access and impersonation.","title":"O365 ApplicationImpersonation Role Assigned","url":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-app-impersonation/"},{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Azure Active Directory","Office 365"],"_cs_severities":["medium"],"_cs_tags":["azuread","o365","persistence"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a compromised user account, potentially through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into the Azure portal using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory section.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target application registration to compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised account to add a new owner to the application registration via the Azure portal or PowerShell cmdlets.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the compromised application registration with malicious settings or permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised application registration to gain unauthorized access to data or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised application registration for persistence within the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;O365 Application Registration Owner Added\u0026quot; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable O365 management activity logging to ensure the necessary events are captured (data_source: \u0026quot;O365 Add owner to application.\u0026quot;).\u003c/li\u003e\n\u003cli\u003eReview and monitor application registration owner assignments for any suspicious or unauthorized changes (references: \u0026quot;https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/overview-assign-app-owners\u0026quot;).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the user and object involved (rule: \u0026quot;O365 Application Registration Owner Added\u0026quot;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-o365-app-owner-added/","summary":"A new owner added to an O365 application registration can grant significant control, potentially leading to unauthorized data access, privilege escalation, or malicious behavior.","title":"O365 Application Registration Owner Added","url":"https://feed.craftedsignal.io/briefs/2024-01-o365-app-owner-added/"},{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Azure AD"],"_cs_severities":["high"],"_cs_tags":["azure","persistence","cloud"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eazure:monitor:aad\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an administrator account through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into the Azure portal using the compromised administrator credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory section.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a malicious application or uses an existing compromised application.\u003c/li\u003e\n\u003cli\u003eThe attacker requests tenant-wide admin consent for the malicious application. This often involves tricking the administrator into approving the request.\u003c/li\u003e\n\u003cli\u003eThe administrator grants consent, either unknowingly or due to social engineering.\u003c/li\u003e\n\u003cli\u003eThe malicious application gains access to data across the entire tenant based on the granted permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the application's permissions to exfiltrate sensitive data, establish persistence, or perform other malicious actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Azure AD Tenant Wide Admin Consent Granted\u0026quot; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all administrator accounts to mitigate the risk of compromised credentials.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit application permissions within Azure AD to identify and remove any unnecessary or overly permissive consents.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for unusual activity, such as unexpected application registrations or consent requests. Enable \u003ccode\u003eazure:monitor:aad\u003c/code\u003e sourcetype and Auditlogs log category.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-ad-admin-consent/","summary":"Detection of admin consent granted to an application within an Azure AD tenant which could lead to data exfiltration and persistence.","title":"Azure AD Tenant Wide Admin Consent Granted","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-ad-admin-consent/"},{"_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":["high"],"_cs_tags":["azure","cloud","persistence","privilege-escalation"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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 \u0026quot;Add owner to application\u0026quot; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises an initial user account or service principal through credential theft or other means (e.g., phishing).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to enumerate existing Service Principals within the Azure AD tenant.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target Service Principal with elevated permissions or access to critical resources.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u0026quot;Add owner to application\u0026quot; operation, adding a new owner (controlled by the attacker) to the target Service Principal. This operation is logged in Azure AD Audit Logs.\u003c/li\u003e\n\u003cli\u003eThe newly added owner account (controlled by the attacker) now has control over the Service Principal.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised Service Principal to access resources and data within the Azure AD environment, bypassing MFA and conditional access controls.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the cloud environment, compromising other services and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which may include data exfiltration, system disruption, or further privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure AD Service Principal Owner Added\u003c/code\u003e to your SIEM and tune for your environment to detect the addition of new owners to Service Principals based on Azure AD Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of Service Principal owner additions for potentially malicious activity, focusing on the \u003ccode\u003einitiatedBy\u003c/code\u003e and \u003ccode\u003enewOwner\u003c/code\u003e fields in the logs.\u003c/li\u003e\n\u003cli\u003eImplement strict controls and monitoring around Service Principal creation and management.\u003c/li\u003e\n\u003cli\u003eReview and reduce the number of Service Principals with excessive privileges.\u003c/li\u003e\n\u003cli\u003eInvestigate related \u003ccode\u003eAzure Active Directory Persistence\u003c/code\u003e and \u003ccode\u003eAzure Active Directory Privilege Escalation\u003c/code\u003e analytic stories after detecting this activity.\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-azure-ad-service-principal-owner-added/","summary":"Detection of a new owner being added to an Azure AD Service Principal, potentially indicating persistence or privilege escalation by an attacker exploiting the lack of multi-factor authentication on service principals.","title":"Azure AD Service Principal Owner Added","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-ad-service-principal-owner-added/"}],"language":"en","title":"CraftedSignal Threat Feed - NOBELIUM Group","version":"https://jsonfeed.org/version/1.1"}