Attack.privilege-Escalation — CraftedSignal Threat Feed

Malicious Usage of AWS IMDS Credentials Outside of Expected Services

hello@craftedsignal.io — Thu, 11 Jul 2024 00:00:00 +0000

This activity focuses on the potential misuse of AWS Instance Metadata Service (IMDS) credentials. When an EC2 instance is compromised, an attacker can extract the temporary credentials stored within the IMDS. These credentials, associated with an assumed role, grant the attacker the ability to interact with other AWS services. The abnormal use of these credentials outside of the expected AWS Simple Systems Manager (SSM) service may indicate malicious activity such as lateral movement, data exfiltration, or resource compromise. This is particularly concerning when the compromised instance is being used as a pivot point to access other AWS resources.

Attack Chain

An EC2 instance is compromised through an initial access vector (e.g., software vulnerability, misconfiguration, or credential compromise).
The attacker gains access to the compromised EC2 instance’s operating system.
The attacker queries the IMDS endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) to obtain temporary AWS credentials associated with the instance’s IAM role.
The attacker configures their local AWS CLI or SDK with the exfiltrated credentials.
The attacker attempts to perform actions against other AWS services using the exfiltrated credentials.
The attacker attempts to escalate privileges or move laterally within the AWS environment.
The attacker attempts to access, modify, or exfiltrate sensitive data from other AWS services.
The attacker maintains persistence by creating new IAM users or roles with excessive permissions.

Impact

Successful exploitation can lead to unauthorized access to sensitive data stored in AWS services such as S3, DynamoDB, and RDS. This could result in data breaches, financial loss, and reputational damage. Attackers can also leverage the compromised credentials to pivot to other AWS resources, potentially impacting critical infrastructure and services. Organizations with lax security configurations and overly permissive IAM roles are at higher risk.

Recommendation

Deploy the Sigma rule “Malicious Usage Of IMDS Credentials Outside Of AWS Infrastructure” to your SIEM and tune for your environment to detect anomalous use of IMDS credentials.
Review and restrict IAM roles assigned to EC2 instances to follow the principle of least privilege, limiting the scope of potential damage from credential exfiltration.
Monitor CloudTrail logs for unusual API calls originating from EC2 instances with assumed roles, specifically those not related to SSM.
Harden EC2 instances to prevent initial compromise by applying security patches, configuring strong authentication, and regularly scanning for vulnerabilities.

Unauthorized Modification of Azure Conditional Access Policy

hello@craftedsignal.io — Wed, 29 May 2024 12:00:00 +0000

Compromised or malicious actors may attempt to modify Azure Conditional Access (CA) policies to weaken security controls, elevate privileges, or establish persistence within the Azure environment. Conditional Access policies are critical for enforcing organizational security standards, and unauthorized changes can have significant security implications. This activity is detected through Azure Audit Logs by monitoring for “Update conditional access policy” events. Defenders should investigate any modifications to Conditional Access policies to ensure they are legitimate and align with security best practices. Detecting and responding to unauthorized CA policy modifications is crucial for maintaining the integrity and security of the Azure environment.

Attack Chain

Initial Access: The attacker gains initial access through compromised credentials or other means (not specified in source).
Privilege Escalation: The attacker leverages existing privileges or exploits vulnerabilities to gain sufficient permissions to modify Conditional Access policies (e.g., through a compromised Global Administrator account).
Policy Enumeration: The attacker enumerates existing Conditional Access policies to identify targets for modification using tools like Azure PowerShell or the Azure portal.
Policy Modification: The attacker modifies a Conditional Access policy, for example, by weakening MFA requirements, excluding specific users or groups from the policy, or disabling the policy altogether.
Persistence: By weakening or disabling Conditional Access policies, the attacker establishes a persistent foothold in the environment, allowing them to bypass security controls and maintain unauthorized access.
Credential Access: With weakened MFA or other access controls, the attacker gains easier access to sensitive credentials.
Defense Impairment: The modification of CA policies impairs the organization’s defense mechanisms, making it easier for the attacker to perform malicious activities undetected.

Impact

Successful modification of Conditional Access policies can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. The number of affected users and resources depends on the scope of the modified policies. Organizations may experience data loss, financial losses, and reputational damage.

Recommendation

Deploy the “CA Policy Updated by Non Approved Actor” Sigma rule to your SIEM to detect unauthorized modifications to Conditional Access policies within your Azure environment.
Review the properties.message field in the Azure Audit Logs for “Update conditional access policy” events and compare “old” vs “new” values to understand the nature of the changes.
Implement strict role-based access control (RBAC) to limit the number of users who can modify Conditional Access policies.
Investigate any alerts generated by the Sigma rule and verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
Enable multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise (related to attack.credential-access tag).

Azure AD Root Certificate Authority Added for Passwordless Authentication

hello@craftedsignal.io — Wed, 08 May 2024 18:22:00 +0000

The addition of a new root certificate authority (CA) in Azure Active Directory (Azure AD) to support certificate-based authentication (CBA) can be a sign of malicious activity. While CBA offers passwordless authentication benefits, attackers can abuse it to establish persistent access, escalate privileges, or evade detection. An attacker with sufficient privileges in the Azure AD tenant can add a rogue CA, enabling them to authenticate as any user within the directory, even without their password. This bypasses multi-factor authentication (MFA) and grants unauthorized access to sensitive resources and data. Defenders should monitor Azure AD audit logs for unexpected modifications to the TrustedCAsForPasswordlessAuth setting, as this could indicate a compromised administrator account or an insider threat attempting to establish a backdoor.

Attack Chain

Compromise an Azure AD administrator account with sufficient privileges to modify tenant-wide settings. This may be achieved through phishing, credential stuffing, or exploiting vulnerabilities.
The attacker authenticates to the Azure portal or uses PowerShell cmdlets to interact with Azure AD.
The attacker executes commands to add a new, attacker-controlled root certificate authority to the TrustedCAsForPasswordlessAuth setting. This involves modifying the Company Information object.
The attacker generates or obtains a certificate signed by the newly added root CA.
The attacker uses the certificate to authenticate to Azure AD as a targeted user, bypassing password requirements and multi-factor authentication.
The attacker gains access to the targeted user’s resources, such as email, files, and applications.
The attacker escalates privileges within the Azure AD tenant by impersonating highly privileged users or roles.
The attacker maintains persistent access to the Azure AD tenant, even if the compromised administrator account is remediated.

Impact

A successful attack can lead to complete compromise of the Azure AD tenant, including access to sensitive data, applications, and resources. Attackers can use the compromised tenant to move laterally to other systems, exfiltrate data, or disrupt business operations. The number of potential victims is dependent on the size of the Azure AD tenant. Organizations across all sectors are at risk, especially those heavily reliant on Azure AD for identity and access management.

Recommendation

Deploy the Sigma rule “New Root Certificate Authority Added” to your SIEM to detect unauthorized modifications to the TrustedCAsForPasswordlessAuth setting (rule).
Review Azure AD audit logs regularly for suspicious activity related to the “Set Company Information” operation (logsource).
Implement multi-factor authentication (MFA) for all Azure AD accounts, including administrators, but understand that CBA can bypass it.
Enforce the principle of least privilege and restrict the number of accounts with permissions to modify tenant-wide settings.
Monitor for the use of certificates signed by unknown or untrusted CAs to authenticate to Azure AD.
Consult the SpecterOps and Goodworkaround articles for more information on certificate-based authentication abuse in Azure AD (references).

Azure AD Sign-in from New Country/Region

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

This threat brief focuses on detecting suspicious sign-in activity within Azure Active Directory (Azure AD). Specifically, it targets sign-ins originating from countries or regions that are new or unusual for a given user. This behavior can be indicative of compromised credentials, travel without notification, or the use of VPN/proxy services to mask the true origin of the sign-in. Microsoft Entra ID Protection identifies “new country” as a risk event when a user signs in from a location that is drastically different from their recent sign-in history. Detecting these anomalies is crucial for preventing unauthorized access and mitigating potential data breaches. The detection uses Azure AD’s risk detection logs to identify such events.

Attack Chain

Initial Access: An attacker gains access to a valid user’s credentials, potentially through phishing, credential stuffing, or malware. (T1078)
Anomalous Login: The attacker attempts to sign in to Azure AD using the compromised credentials from a country or region not typically associated with the user.
Risk Detection Trigger: Azure AD Identity Protection identifies the sign-in as high-risk due to the new country/region and logs a “newCountry” risk event.
Persistence: The attacker may establish persistent access by creating new accounts or modifying existing ones.
Privilege Escalation: If the compromised account has elevated privileges, the attacker may attempt to escalate their privileges within the Azure environment.
Lateral Movement: The attacker may use the compromised account to move laterally within the organization, accessing other resources and data.
Data Exfiltration: The attacker accesses sensitive data and attempts to exfiltrate it from the environment.
Impact: The attacker achieves their objectives, which could include data theft, financial fraud, or disruption of services.

Impact

A successful attack following a sign-in from a new country can result in unauthorized access to sensitive data, compromised user accounts, and potential data breaches. Organizations may experience financial losses, reputational damage, and legal liabilities. The number of victims and the extent of the damage depend on the privileges of the compromised account and the attacker’s objectives. Immediate containment is crucial to prevent further damage if a new country sign-in is verified as malicious.

Recommendation

Deploy the provided Sigma rule to your SIEM or security analytics platform to detect “newCountry” risk events in Azure AD (logsource: azure, service: riskdetection).
Investigate any alerts generated by the Sigma rule in the context of other sign-in activities for the affected user to rule out false positives.
Implement multi-factor authentication (MFA) for all users to mitigate the risk of account compromise (T1078).
Monitor user activity logs for other suspicious behaviors, such as unusual access patterns or attempts to escalate privileges.
Review and enforce conditional access policies to restrict access based on location, device, and other factors.
Educate users about phishing and other social engineering tactics to prevent credential theft.

Windows Registry Classes Autorun Keys Modification for Persistence

hello@craftedsignal.io — Sun, 28 Jan 2024 12:00:00 +0000

Attackers can manipulate Windows Registry Classes keys, an autostart extensibility point (ASEP), to achieve persistence. This involves modifying registry entries that control how the operating system handles specific file types or shell actions. By modifying these keys, adversaries can ensure their malicious code executes whenever a user interacts with a specific file type (e.g., opening an .exe) or performs a specific action within the shell. This technique, which has been observed since at least 2019, allows malicious actors to maintain a persistent foothold on compromised systems. While legitimate software also utilizes these registry keys, careful filtering and monitoring are crucial for distinguishing malicious modifications from benign software installations. Detection can be noisy due to the legitimate use of these keys, so tuning and review is critical.

Attack Chain

Initial Access: The attacker gains initial access through a separate vector (e.g., phishing, exploit). This stage is not covered by this detection, which focuses on post-exploitation activity.
Privilege Escalation (if needed): The attacker may need elevated privileges to modify certain registry keys. This can involve exploiting vulnerabilities or leveraging existing administrative rights.
Registry Key Modification: The attacker modifies specific keys under \Software\Classes in the Windows Registry. Common targets include \Folder\ShellEx\ExtShellFolderViews, \.exe, and \Directory\Shellex\DragDropHandlers.
Payload植入：攻击者修改注册表项指向一个恶意可执行文件或脚本。这可能涉及替换默认命令或添加新的处理程序。
Execution Trigger: The malicious code is configured to execute when a user interacts with the associated file type or shell action (e.g., opening a .exe file, right-clicking a folder).
Malicious Payload Execution: When the configured trigger occurs, the malicious payload executes, giving the attacker control over the system.
Persistence Maintained: The modified registry keys ensure that the malicious payload will continue to execute whenever the trigger occurs, maintaining persistence across reboots or user logons.
Objective Achieved: The attacker leverages persistent access to achieve their objectives, such as data exfiltration, lateral movement, or deploying ransomware.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems, bypassing traditional security measures. This can lead to significant data breaches, financial losses, and reputational damage. The number of potential victims is broad, as any Windows system is potentially vulnerable. The types of damage possible range from credential theft to ransomware deployment, depending on the attacker’s objectives.

Recommendation

Enable Windows Registry auditing and monitor registry_set events for modifications to keys under \Software\Classes to identify suspicious activity.
Deploy the Sigma rule “Classes Autorun Keys Modification” to your SIEM and tune the filters (filter_main_, filter_optional_) for your specific environment to reduce false positives.
Investigate any registry modifications detected by the Sigma rule, focusing on unusual executables or scripts being launched from these locations.
Regularly review and update the filters in the Sigma rule to account for legitimate software changes in your environment.

User Added to Group with Conditional Access Policy Modification Access

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

This activity involves the addition of a user to an Azure Active Directory group that possesses the ability to modify Conditional Access (CA) policies. Conditional Access policies are used to enforce authentication requirements based on various conditions (user, location, device, etc.). If an attacker gains the ability to modify these policies, they can weaken security controls to facilitate privilege escalation, credential access, persistence within the environment, and impair defenses. This type of attack can be initiated by an insider threat or external compromise of an account. The goal is to manipulate CA policies to bypass multi-factor authentication, grant unauthorized access, or maintain persistence.

Attack Chain

The attacker gains initial access to a user account or service principal with sufficient privileges to manage group memberships in Azure AD. This could be achieved through credential compromise or other initial access vectors.
The attacker identifies a target Azure AD group that has permissions to manage Conditional Access policies. These groups are often used to delegate administrative control over CA policies.
The attacker uses the Azure portal, PowerShell, or the Azure AD Graph API/Microsoft Graph API to add a malicious user account to the target group.
The Azure Audit Logs record the “Add member from group” event, indicating the change in group membership.
The newly added malicious user inherits the group’s permissions, which includes the ability to view, create, modify, and delete Conditional Access policies.
The attacker modifies existing CA policies to weaken security controls. For example, they might exclude themselves from MFA requirements or grant access to sensitive resources without proper authorization.
The attacker leverages their modified CA policies to gain unauthorized access to sensitive data or resources.
The attacker establishes persistence by creating new CA policies that ensure their continued access, even if their initial access is revoked.

Impact

Successful exploitation of this attack chain can lead to significant compromise of an organization’s Azure environment. Attackers can bypass MFA, gain access to sensitive resources, establish persistent access, and impair security defenses. The extent of the damage depends on the permissions associated with the compromised group and the scope of the modified Conditional Access policies. This can lead to data breaches, financial loss, and reputational damage.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect additions of users to groups with CA policy modification access and tune for your environment.
Regularly review and audit Azure AD group memberships, especially for groups with administrative privileges (as detected by the Sigma rule).
Implement multi-factor authentication for all users, especially those with administrative privileges.
Enforce the principle of least privilege when assigning permissions to Azure AD groups.
Monitor Azure AD audit logs for suspicious activity related to group membership changes and Conditional Access policy modifications.

Azure AD Authentication to Important Apps Using Single-Factor Authentication

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

This alert focuses on detecting potentially risky authentication events within Azure Active Directory. Specifically, it flags successful logins to applications deemed “important” where the authentication process only involved a single factor. This bypasses the added security of multi-factor authentication (MFA), potentially exposing these applications to compromise if the single factor (e.g., password) is weak, stolen, or compromised. The alert is designed to identify deviations from a secure authentication baseline, particularly in environments where MFA is expected for sensitive resources. The applications considered “important” must be pre-defined by the defender for this detection to function effectively.

Attack Chain

An attacker gains access to a valid username and password through phishing, credential stuffing, or other means.
The attacker attempts to authenticate to a pre-defined, high-value application within the Azure AD environment.
Azure AD processes the authentication request.
The application is configured to allow single-factor authentication.
Azure AD verifies the supplied username and password against its directory.
Upon successful verification, Azure AD grants the attacker access to the application.
The attacker gains unauthorized access to the application’s data and functionality.
Depending on the application and attacker’s motives, this could lead to data exfiltration, privilege escalation, or other malicious activities.

Impact

The impact of successful single-factor authentication to critical applications can range from minor data breaches to significant compromises of sensitive systems. The number of potential victims depends on the application’s user base and the sensitivity of the data it manages. Sectors most at risk include those handling financial, healthcare, or sensitive personal information. A successful attack could lead to data theft, financial loss, reputational damage, and regulatory penalties.

Recommendation

Populate the AppId field in the Sigma rule with the Application IDs of your organization’s critical applications.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the single-factor authentication.
Enforce multi-factor authentication (MFA) for all users accessing critical applications to mitigate the risk of credential compromise.
Review and update Azure AD Conditional Access policies to ensure appropriate authentication requirements are in place.
Tune the Sigma rule based on observed false positives in your environment.

Detection of Azure Subscription Permission Elevation

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

This threat brief focuses on detecting unauthorized elevation of privileges within Azure environments. Specifically, it addresses the assignment of the ‘User Access Administrator’ role to a user, which allows managing access to all Azure subscriptions. This activity can be indicative of malicious actors attempting to gain control over an Azure environment or an insider threat escalating their privileges without proper authorization. The detection is based on Azure Audit Logs and can help identify potentially compromised accounts or misconfigurations. A successful elevation can lead to unauthorized access, data breaches, and service disruptions. Defenders should closely monitor these events and investigate any unexpected privilege escalations.

Attack Chain

An attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability.
The attacker attempts to assign the ‘User Access Administrator’ role to themselves or another account they control.
This assignment generates an ‘Administrative’ audit log event with the OperationName ‘Assigns the caller to user access admin’.
The attacker now has the ability to manage user access to all Azure subscriptions within the tenant.
The attacker creates new user accounts with elevated privileges within the subscriptions.
The attacker leverages the newly created accounts to access sensitive resources and data.
The attacker performs reconnaissance activities to identify critical assets and data stores.
The attacker exfiltrates sensitive data or deploys malicious workloads within the compromised subscriptions.

Impact

A successful privilege escalation to the ‘User Access Administrator’ role can have severe consequences. It grants the attacker complete control over the Azure subscriptions, allowing them to access sensitive data, disrupt services, and potentially compromise the entire cloud environment. The number of affected subscriptions depends on the scope of the compromised account. This attack targets any organization utilizing Azure subscriptions and is particularly impactful for those storing sensitive data or running critical applications in the cloud.

Recommendation

Deploy the provided Sigma rule “Azure Subscription Permission Elevation Via AuditLogs” to your SIEM and tune it for your environment to detect the ‘Assigns the caller to user access admin’ event in the Azure Audit Logs.
Investigate any detected instances of this event to determine if the privilege elevation was authorized and legitimate.
Review and enforce the principle of least privilege for all Azure accounts to minimize the impact of potential compromises; reference the Microsoft Entra documentation for guidance.
Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to prevent unauthorized access via compromised credentials.

Azure AD Successful Authentication Increase

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

This alert identifies a potentially malicious increase in successful sign-ins within an Azure Active Directory environment. An attacker who has compromised credentials may attempt to leverage them repeatedly, resulting in a higher-than-normal volume of successful authentications. While not definitive proof of compromise, a sudden spike warrants further investigation. This behavior is typically observed during the initial access, persistence, privilege escalation, or stealth phases of an attack. This detection focuses on identifying increases of 10% or greater, providing a starting point for identifying anomalous activity. Defenders should investigate the source of the increase, focusing on specific users, applications, or geographic locations involved.

Attack Chain

Credential Compromise: The attacker obtains valid user credentials through phishing, brute-force, or credential stuffing attacks against Azure AD.
Initial Access: The attacker uses the compromised credentials to successfully authenticate to Azure AD, gaining initial access to the environment (T1078).
Enumeration: The attacker enumerates available resources, applications, and user accounts within the Azure AD environment.
Privilege Escalation: The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in Azure AD or related applications. This may involve authenticating to multiple resources.
Persistence: The attacker establishes persistence mechanisms, such as creating new accounts or modifying existing ones, to maintain access to the environment. This may involve repeatedly authenticating to refresh tokens or maintain sessions.
Lateral Movement: The attacker uses the compromised account to access other resources or accounts within the Azure AD environment, potentially triggering further successful sign-ins.
Data Exfiltration or Damage: The attacker uses the compromised access to exfiltrate sensitive data or disrupt business operations.
Covering Tracks: The attacker attempts to cover their tracks by disabling logging or deleting audit trails to avoid detection.

Impact

A successful attack following a measurable increase in authentications can lead to unauthorized access to sensitive data, financial loss, reputational damage, and disruption of business operations. The specific impact depends on the level of access gained by the attacker and the resources they are able to compromise. For example, an attacker gaining access to an administrator account could potentially take control of the entire Azure AD environment.

Recommendation

Deploy the “Measurable Increase Of Successful Authentications” Sigma rule to your SIEM and tune for your environment. This rule detects increases of 10% or greater in successful sign-ins (rule, logsource: azure, service: signinlogs).
Investigate any alerts generated by the Sigma rule, focusing on identifying the source of the increased authentications and the users/applications involved.
Review the Microsoft Entra ID Protection reports for unusual sign-in activity, as referenced in the source material: https://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins.
Implement multi-factor authentication (MFA) for all users to reduce the risk of credential compromise.
Monitor for other suspicious activities, such as unusual sign-in locations, access to sensitive resources, or changes to user accounts.

Unauthorized Conditional Access Policy Creation in Azure AD

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

This threat brief addresses the creation of a new Conditional Access (CA) policy within Azure Active Directory (Azure AD) by an actor not authorized to perform such actions. Conditional Access policies are critical security controls that enforce organizational policies based on various conditions, such as user identity, location, device, and application. Unauthorized modification or creation of these policies can lead to significant security breaches, allowing attackers to bypass security controls, escalate privileges, and gain unauthorized access to sensitive resources. This activity is detected via Azure Audit Logs.

Attack Chain

Initial Access: The attacker gains initial access to an account with sufficient privileges to interact with Azure AD, potentially through compromised credentials or an insider threat.
Privilege Escalation (If Needed): The attacker escalates privileges within Azure AD to a role that permits the creation or modification of Conditional Access policies.
Policy Creation: The attacker creates a new Conditional Access policy using the Azure portal, PowerShell, or Azure CLI.
Policy Configuration: The attacker configures the CA policy to weaken security controls, such as disabling MFA for specific users, locations, or applications.
Bypass Security Controls: The newly created or modified CA policy allows the attacker to bypass intended security controls, granting them unauthorized access.
Lateral Movement: With bypassed security controls, the attacker moves laterally within the network, accessing sensitive resources and data.
Data Exfiltration/Impact: The attacker achieves their final objective, such as exfiltrating sensitive data or causing disruption to business operations.

Impact

The creation of unauthorized Conditional Access policies can have severe consequences, including unauthorized access to sensitive data, privilege escalation, and circumvention of security controls. The impact can range from data breaches and financial loss to reputational damage and disruption of critical business services. If successful, attackers could gain complete control over the Azure AD environment, affecting all connected services and applications.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized CA policy creation events in Azure Audit Logs.
Review Azure AD role assignments to ensure least privilege and restrict CA policy management to authorized personnel only.
Investigate any alerts generated by the Sigma rule to identify the actor and the details of the created CA policy.
Implement multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise.
Monitor Azure AD audit logs for other suspicious activities, such as changes to user accounts, group memberships, and application registrations.
Establish a baseline of expected CA policy configurations and alert on deviations from this baseline.

Office Application Autorun Registry Key Modification

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

Attackers may target Microsoft Office applications’ autostart extensibility points (ASEPs) in the Windows Registry to establish persistence. By modifying specific registry keys, malicious actors can ensure that their code is executed each time an Office application, such as Word, Excel, or Outlook, is launched. This technique is often employed to maintain a foothold on a compromised system. While legitimate add-ins also leverage these registry keys, unauthorized modifications can lead to the execution of arbitrary code, potentially resulting in data theft, system compromise, or further exploitation. Defenders should be aware that many legitimate applications modify these keys. Thorough testing and tuning is required.

Attack Chain

An attacker gains initial access to the system via an unrelated method.
The attacker identifies the relevant Office application ASEP registry keys: \Software\Wow6432Node\Microsoft\Office, \Software\Microsoft\Office and specific application keys like \Word\Addins, \Excel\Addins, etc.
The attacker modifies the registry key to point to a malicious executable or script. This could be achieved using tools like reg.exe or PowerShell.
The registry modification ensures that the malicious code is executed upon the next launch of the targeted Office application.
The user launches the Office application (e.g., Word, Excel, Outlook).
The Office application reads the modified registry key and executes the associated malicious code.
The malicious code performs its intended actions, such as downloading additional payloads, establishing command and control, or stealing data.
The attacker maintains persistence on the system through the modified registry key, ensuring continued access and control.

Impact

Successful exploitation allows attackers to achieve persistence on compromised systems. This can lead to data exfiltration, deployment of ransomware, or further lateral movement within the network. The modification of these keys is often performed to maintain a persistent presence, allowing attackers to regain access to the system even after reboots or user logoffs. While the number of direct victims is unknown, the potential for widespread impact is significant, especially in organizations heavily reliant on Microsoft Office applications.

Recommendation

Enable registry modification logging and deploy the provided Sigma rules to your SIEM to detect suspicious changes to Office application autostart registry keys.
Regularly audit the Office application add-ins installed on systems to identify and remove any unauthorized or malicious extensions (reference: Sigma rules).
Implement application whitelisting to prevent the execution of unauthorized executables and scripts (reference: Attack Chain).
Monitor process execution events for Office applications launching unusual or suspicious child processes (reference: Attack Chain).
Tune and customize the provided Sigma rules based on your environment’s baseline of legitimate Office add-in activity to minimize false positives (reference: Sigma rules).

Detection of Important Scheduled Task Deletion or Disablement

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

This brief focuses on the detection of malicious activity related to the deletion or disabling of important scheduled tasks within a Windows environment. Adversaries may target these tasks to disrupt normal system operations, escalate privileges, establish persistence, or facilitate data destruction. The targeted tasks often include critical system functions like System Restore, Windows Defender updates, BitLocker encryption, Windows Backup processes, and Windows Update mechanisms. This…

Azure AD User Added to Administrator Role

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

Attackers may attempt to add new members to administrative roles in Azure Active Directory to establish persistence and elevate privileges. This allows them to perform actions as a highly privileged user, potentially bypassing security controls and accessing sensitive resources. The activity is logged within Azure Activity Logs, specifically when the ‘Add member to role’ operation is executed within the ‘AzureActiveDirectory’ workload, targeting roles with names ending in ‘Admins’ or ‘Administrator’. Monitoring these events can help detect unauthorized privilege escalation and potential malicious activity within the Azure environment. This activity could be the result of compromised credentials or an insider threat.

Attack Chain

Compromise an existing user account with sufficient permissions to modify Azure AD roles.
Authenticate to the Azure portal or utilize Azure CLI with the compromised account.
Identify a target Azure AD administrative role (e.g., Global Administrator, Security Administrator).
Execute the ‘Add member to role’ operation, adding the attacker-controlled user to the target role. This can be performed via the Azure portal, PowerShell, or Azure CLI.
The Azure Activity Logs record the ‘Add member to role.’ event, with the ‘Workload’ as ‘AzureActiveDirectory’.
The ModifiedProperties{}.NewValue field reflects the addition of the user to the admin role, containing strings like “Admins” or “Administrator.”
The attacker authenticates as the newly added user, inheriting the privileges of the administrative role.
The attacker leverages the elevated privileges to access sensitive data, modify configurations, or deploy malicious applications.

Impact

Successful addition of a user to an Azure AD administrative role grants the attacker extensive control over the Azure environment. This can lead to data breaches, service disruptions, and the deployment of malicious applications. Compromised administrator accounts can be used to disable security features, modify audit logs, and create backdoors for persistent access. Detection is critical to limit the scope and duration of the attack.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect instances of users being added to Azure AD administrative roles (logsource: azure, service: activitylogs).
Investigate any detected instances of the “Add member to role.” operation in Azure AD Activity Logs where the ModifiedProperties{}.NewValue ends with ‘Admins’ or ‘Administrator’ to validate legitimate administrative changes.
Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of compromised credentials.
Regularly review Azure AD role assignments to identify and remove unnecessary privileges.
Monitor for unusual activity from newly added members of administrative roles after the ‘Add member to role’ event.

AWS STS AssumeRole Misuse for Lateral Movement and Privilege Escalation

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

The AWS Security Token Service (STS) AssumeRole function allows users or applications to assume a different IAM role, granting temporary access to resources and permissions associated with that role. Attackers who gain initial access to an AWS account can misuse AssumeRole to move laterally to other roles and escalate their privileges. This can occur if the initial role has overly permissive trust relationships or if an attacker can manipulate the role assumption process. This activity is detected through CloudTrail logs that record the AssumeRole event. The impact of this activity can be significant, depending on the permissions associated with the roles assumed.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies IAM roles within the AWS environment that they may be able to assume.
The attacker attempts to use the AssumeRole API call to assume a different role. This call includes parameters specifying the target role ARN and a session name.
AWS STS validates the request. Successful validation depends on the trust policy of the target role and the permissions of the initial user or role.
If the validation is successful, AWS STS returns temporary security credentials (access key ID, secret access key, and session token) to the attacker.
The attacker uses these temporary credentials to access AWS resources and perform actions authorized by the assumed role.
The attacker continues to move laterally and escalate privileges by assuming additional roles.
The attacker achieves their objective, such as accessing sensitive data, modifying configurations, or disrupting services.

Impact

Successful exploitation can lead to a wide range of impacts, including unauthorized access to sensitive data stored in S3 buckets or databases, modification or deletion of critical infrastructure configurations, and disruption of AWS services. The scope of the impact depends on the permissions associated with the roles that the attacker is able to assume. This can affect any organization using AWS, and the consequences can range from data breaches and financial losses to reputational damage and regulatory penalties.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect suspicious AssumeRole activity based on userIdentity.type and userIdentity.sessionContext.sessionIssuer.type.
Review and harden IAM role trust policies to ensure that only authorized entities can assume roles.
Monitor CloudTrail logs for unusual patterns of AssumeRole API calls, especially those originating from unfamiliar user identities or locations.
Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise.

Azure PIM - Role Assignment Outside of Privileged Identity Management

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

The unauthorized assignment of privileged roles outside of Azure Privileged Identity Management (PIM) represents a significant security risk. Attackers may attempt to bypass PIM controls to gain persistent access, escalate privileges, or move laterally within the Azure environment. Detecting these anomalous role assignments is crucial for identifying potentially compromised accounts or malicious insiders. This activity is a common tactic used by attackers to establish persistence and maintain control over cloud resources. Monitoring for this behavior can help security teams quickly identify and respond to potential breaches, limiting the impact of successful attacks. This activity can be associated with lateral movement, privilege escalation, and persistence within the cloud environment.

Attack Chain

An attacker gains initial access to a compromised user account or service principal within the Azure environment.
The attacker attempts to identify existing privileged roles and permissions.
The attacker bypasses PIM to directly assign themselves a privileged role (e.g., Global Administrator, Security Administrator) using Azure CLI, PowerShell, or the Azure portal.
The attacker elevates their permissions without triggering PIM alerts or requiring approval.
The attacker uses the newly assigned privileged role to access sensitive data, modify configurations, or create new resources.
The attacker establishes persistence by creating new accounts or modifying existing ones with elevated privileges.
The attacker moves laterally to other Azure resources or subscriptions using their increased access.
The attacker achieves their final objective, such as data exfiltration, service disruption, or deployment of malicious code.

Impact

Compromising privileged roles within Azure can have severe consequences, potentially impacting all resources within the affected Azure Active Directory tenant. Successful attacks can lead to unauthorized data access, service disruption, financial loss, and reputational damage. The scope of the impact depends on the level of privilege gained by the attacker and the sensitivity of the targeted resources. Without proper detection and response, organizations may remain unaware of the breach, allowing attackers to maintain persistent access and continue their malicious activities undetected.

Recommendation

Deploy the provided Sigma rule Roles Assigned Outside PIM to your SIEM to detect unauthorized role assignments within your Azure environment.
Investigate all instances flagged by the Sigma rule Roles Assigned Outside PIM to determine the legitimacy of the role assignment and the identity of the assigner.
Implement controls to restrict the ability to assign privileged roles outside of PIM, as described in the Microsoft documentation reference.
Review and enforce the principle of least privilege to minimize the potential impact of compromised accounts.