Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker escalates privileges to gain the necessary permissions to delete files.
3. The attacker deploys or utilizes an existing copy of the SDelete utility.
4. The attacker executes SDelete against targeted files or directories.
5. SDelete overwrites the targeted file(s) multiple times with random data.
6. SDelete renames the file(s) multiple times, often with patterns such as “*AAA.AAA”.
7. SDelete deletes the file(s) making recovery difficult.
8. The attacker removes SDelete or any associated tools to further cover their tracks.

Impact

Successful exploitation of this technique can result in the permanent deletion of crucial forensic artifacts, log files, or even critical data. This can severely hinder incident response efforts, making it challenging to identify the scope of the attack, the attacker’s methods, and the compromised assets. The number of victims and affected sectors depends on the scale of the initial breach and the attacker’s objectives.

Recommendation

• Deploy the “Potential Secure File Deletion via SDelete Utility” detection rule to your SIEM and tune for your environment.
• Investigate any alerts generated by the detection rule, focusing on the process execution chain and identifying the user account involved.
• Review the privileges assigned to the user account to ensure the least privilege principle is followed.
• Enable Sysmon Event ID 11 (File Create) logging to enhance visibility into file creation events.

Attack Chain

1. Initial Access: An attacker gains unauthorized access to a GitHub account with sufficient privileges. This could be achieved through compromised credentials or insider access.
2. Privilege Escalation (Optional): The attacker escalates privileges within the GitHub organization to gain the necessary permissions to delete resources if they don’t already have them.
3. Reconnaissance: The attacker identifies valuable codespaces, environments, projects, or repositories within the GitHub organization that they intend to delete.
4. Deletion of Codespaces: The attacker executes the codespaces.destroy action, deleting a specific codespace instance, potentially disrupting development workflows.
5. Deletion of Environments: The attacker executes the environment.delete action, removing a specific environment configuration, potentially affecting deployment processes.
6. Deletion of Projects: The attacker executes the project.delete action, deleting a project board and its associated tasks, impacting project management.
7. Deletion of Repositories: The attacker executes the repo.destroy action, permanently deleting a repository, leading to code loss and potential service disruption.
8. Impact: The deletion of critical resources disrupts development workflows, causes data loss, and potentially compromises the software development lifecycle.

Impact

Successful execution of these actions can lead to significant disruption of software development workflows, data loss, and potential compromise of the software supply chain. The number of affected resources and the severity of the impact depend on the scope of the attacker’s access and the criticality of the deleted resources.

Recommendation

• Enable GitHub audit log streaming to capture the necessary events for detection (reference: logsource definition).
• Deploy the provided Sigma rule to detect codespaces.destroy, environment.delete, project.delete, and repo.destroy actions in the GitHub audit logs, and tune for your environment (reference: rules).
• Investigate any alerts triggered by the Sigma rule to determine the legitimacy of the deletion activity and the actor involved (reference: rules, falsepositives).
• Validate the “actor” field in the audit logs to ensure the deletion activity is performed by an authorized user (reference: falsepositives).

Attack Chain

Given the broad nature of the advisory, the following attack chain is constructed based on the potential capabilities granted by exploiting the vulnerabilities:

1. Initial Access: An attacker exploits a remote code execution vulnerability in Dell PowerProtect Data Domain OS, potentially through a network service or web interface.
2. Privilege Escalation: The attacker leverages an additional vulnerability to escalate privileges from an initial low-privilege shell to root access.
3. Defense Evasion: With root privileges, the attacker disables or bypasses security measures, such as intrusion detection systems or anti-malware software.
4. Credential Access: The attacker gains access to stored credentials, such as those used for backups or system administration, by dumping the system’s credential store.
5. Data Manipulation: The attacker modifies data stored within the Dell PowerProtect Data Domain system, potentially corrupting backups or injecting malicious code into stored files.
6. Information Disclosure: The attacker extracts sensitive information, such as customer data, internal documents, or system configurations.
7. Lateral Movement: Using the compromised Data Domain OS, the attacker can pivot to other systems within the network leveraging the credentials obtained or the trust relationships established.
8. Impact: The attacker achieves their final objective, which may include data exfiltration, system disruption, or ransomware deployment.

Impact

Successful exploitation of these vulnerabilities could result in significant damage to organizations utilizing Dell PowerProtect Data Domain OS. This could include data loss due to corruption or deletion, financial losses from service disruption, reputational damage, and legal repercussions from the disclosure of sensitive information. The absence of specific victim counts or sector targeting makes quantifying the impact difficult, but the potential for widespread disruption and data compromise is high.

Recommendation

• Investigate Dell’s security advisories and apply the necessary patches to address the vulnerabilities in PowerProtect Data Domain OS as soon as they become available.
• Implement network segmentation to limit the potential impact of a compromised Data Domain OS on other systems.
• Enable logging on Dell PowerProtect Data Domain OS, including process creation and network connection logs, to detect potential exploitation attempts and investigate suspicious activity, allowing the deployment of the Sigma rules below.
• Monitor for unauthorized access attempts to Dell PowerProtect Data Domain OS through webserver logs, specifically looking for suspicious cs-uri-query strings (see rule “Detect Web Request for Potential Dell PowerProtect Exploit”).

Attack Chain

1. Initial access is gained to an AWS account through compromised credentials or other means (T1078.004).
2. The attacker enumerates existing IAM resources, including SAML providers, using AWS CLI or API calls.
3. The attacker identifies the SAML provider used by administrative or security teams.
4. The attacker executes the DeleteSAMLProvider API call via the AWS CLI, API, or AWS Management Console (T1531).
5. The DeleteSAMLProvider event is logged in AWS CloudTrail with a “success” status.
6. Administrative and security teams lose access to AWS resources that require SAML authentication.
7. The attacker leverages the compromised account to escalate privileges, create new IAM users, or modify existing policies.
8. The attacker persists in the environment, potentially exfiltrating data or deploying malicious workloads (T1485).

Impact

The deletion of an AWS SAML provider can have serious consequences. It disrupts access for administrators and security personnel, delaying incident response and potentially allowing attackers to further compromise the environment. This can lead to data breaches, service disruptions, and financial losses. The severity of the impact depends on the criticality of the affected AWS resources and the speed of detection and recovery.

Recommendation

• Deploy the Sigma rule “AWS SAML Provider Deletion Activity” to your SIEM and tune for your environment to detect this specific event.
• Investigate any DeleteSAMLProvider events in AWS CloudTrail, focusing on the user identity, user agent, and source IP address (logsource: aws/cloudtrail).
• Implement multi-factor authentication (MFA) for all IAM users, especially those with administrative privileges, to reduce the risk of credential compromise (T1110).
• Review and enforce the principle of least privilege for all IAM roles and users to limit the impact of compromised credentials.

Attack Chain

1. An attacker gains unauthorized access to an Okta administrator account, potentially through credential theft or phishing.
2. The attacker authenticates to the Okta administrative console.
3. The attacker navigates to the network zone configuration within the Okta admin console.
4. The attacker identifies a target network zone that restricts access to critical resources.
5. The attacker deactivates the target network zone, effectively disabling its restrictions. Alternatively, the attacker deletes the network zone.
6. The attacker may modify other security settings, such as MFA policies, to further weaken the security posture.
7. The attacker leverages the relaxed network restrictions to access sensitive applications or data from previously unauthorized locations.
8. The attacker performs malicious actions, such as data exfiltration or lateral movement, using the compromised Okta session.

Impact

The deactivation or deletion of an Okta network zone can have serious consequences. It can lead to unauthorized access to sensitive applications and data, potentially resulting in data breaches, financial loss, and reputational damage. The impact is especially high if the affected network zone was protecting critical infrastructure or sensitive customer data. Depending on the scope of access granted, a single deactivated zone could expose data belonging to thousands of users.

Recommendation

• Deploy the “Okta Network Zone Deactivated or Deleted” Sigma rule to your SIEM to detect this activity (logsource: okta, service: okta, eventType: zone.deactivate/zone.delete).
• Investigate any detected instances of network zone deactivation or deletion to determine if they were authorized changes.
• Review Okta administrator account activity for signs of compromise, such as login attempts from unusual locations.
• Enforce multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access.
• Monitor the Okta system logs for other suspicious configuration changes, such as modifications to MFA policies or application assignments.

Attack Chain

1. The attacker gains initial access to a system through an exploit or compromised credentials.
2. The attacker moves laterally to other systems on the network using valid accounts or exploits. (T1021.002 - SMB/Windows Admin Shares)
3. The attacker uses a tool to remotely create files over SMB. (T1021.002 - SMB/Windows Admin Shares)
4. The SYSTEM account (PID 4) on a compromised host is used to create multiple files with the same name but different paths (C:*) over SMB.
5. The created files have file extensions commonly associated with ransom notes: .txt, .htm, .html, .hta, .pdf, .jpg, .bmp, .png.
6. The files are dropped into at least 3 unique paths within a short time frame (60 seconds).
7. The attacker encrypts data and leaves the ransom notes to instruct victims on how to pay the ransom. (T1486 - Data Encrypted for Impact)
8. The organization experiences data loss, financial damage, and reputational harm.

Impact

Successful ransomware attacks can lead to significant data loss, financial costs associated with ransom payments, recovery efforts, and reputational damage. Organizations may experience business disruption, regulatory fines, and legal liabilities. The Akira ransomware group, referenced in the original rule’s documentation, has been known to target various sectors, demanding substantial ransoms from victims. The widespread distribution of ransom notes indicates an advanced stage of the ransomware attack, necessitating immediate containment to prevent further data encryption and system compromise.

Recommendation

• Deploy the Sigma rule Potential Ransomware Note File Dropped via SMB to your SIEM to detect suspicious file creation activity indicative of ransomware deployment.
• Enable Elastic Defend for enhanced endpoint detection and response capabilities, as recommended in the rule’s setup instructions.
• Monitor incoming network connections to port 445 (SMB) on critical assets, as suggested in the rule’s triage analysis.
• Investigate file names with unusual extensions to identify potential ransom notes, as mentioned in the triage analysis.
• Isolate any hosts identified as creating multiple note files over SMB to prevent further lateral movement and data encryption, as described in the rule’s response and remediation steps.
• Review and enforce network segmentation policies to limit lateral movement and reduce the impact of potential ransomware attacks (TA0008).

Attack Chain

1. An attacker gains unauthorized access to a GitHub account with repository administration privileges.
2. The attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.
3. The attacker navigates to the settings page of a target repository.
4. The attacker modifies the repository’s archive status, either archiving or unarchiving it depending on their objective.
5. GitHub logs the ‘repo.archived’ or ‘repo.unarchived’ action in the organization’s audit logs.
6. (If archiving) Legitimate users may lose access to the repository and its code, causing disruption.
7. (If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.
8. The attacker may then attempt to exploit the unarchived repository for further malicious activities.

Impact

The impact of unauthorized repository archiving or unarchiving can range from temporary disruption of services to the reintroduction of vulnerable code. A successful attack could lead to data breaches, code compromise, or supply chain attacks. The number of affected repositories depends on the scope of the attacker’s access and objectives.

Recommendation

• Deploy the Sigma rule “GitHub Repository Archive Status Changed” to your SIEM and tune for your environment. This rule detects the repo.archived and repo.unarchived actions in GitHub audit logs (logsource: github, service: audit).
• Review GitHub audit logs regularly for unexpected repository archiving or unarchiving events.
• Investigate any detected events to determine if the actions were authorized.

Attack Chain

1. Adversary gains initial access to the target Windows system.
2. The attacker performs reconnaissance to identify backup file locations.
3. The attacker uses a non-backup related process (e.g., cmd.exe, powershell.exe) to delete backup files.
4. The attacker targets Veeam backup files with extensions VBK, VIB, and VBM.
5. The attacker targets Veritas Backup Exec files with the BKF extension.
6. The deletion events are logged by the endpoint detection system.
7. The detection rule triggers, identifying the anomalous deletion activity based on file extension and process context.
8. Successful deletion of backups impairs the victim’s ability to recover from ransomware or other destructive attacks.

Impact

Successful deletion of backup files can severely impact an organization’s ability to recover from a ransomware attack or other data loss events. Without viable backups, the victim organization may be forced to pay a ransom or face significant data loss and business disruption. This tactic directly increases the attacker’s leverage and potential financial gain. The rule’s documentation cites a report from AdvIntel detailing backup removal solutions seen with Conti ransomware.

Recommendation

• Deploy the Sigma rule Unexpected Veeam Backup File Deletion to your SIEM and tune for your environment to detect unexpected deletion of Veeam backup files.
• Deploy the Sigma rule Unexpected Veritas Backup File Deletion to your SIEM and tune for your environment to detect unexpected deletion of Veritas Backup Exec files.
• Investigate any alerts generated by these rules to determine the source of the deletion and assess potential impact.
• Enable endpoint file event logging to capture file deletion events, which are crucial for the Sigma rules.
• Review process execution chains (parent process tree) for unknown processes to identify the root cause of unexpected file deletions.

Attack Chain

1. Initial Access: The attacker gains initial access to the system through various means, such as phishing or exploiting a vulnerability.
2. Privilege Escalation: The attacker escalates privileges to gain administrative access, required to modify boot configuration settings.
3. Reconnaissance: The attacker performs reconnaissance to identify the system’s configuration and identify appropriate targets for modification.
4. Disable Recovery: The attacker uses bcdedit.exe to disable Windows Error Recovery using the /set {default} recoveryenabled No command.
5. Ignore Boot Failures: The attacker uses bcdedit.exe to set the boot status policy to ignore all failures using the /set {default} bootstatuspolicy ignoreallfailures command.
6. System Impact: By modifying the boot configuration, the attacker inhibits system recovery, making it harder for the system to recover from errors or malicious activity.
7. Payload Execution: The attacker deploys and executes the primary malicious payload, such as ransomware, leveraging the modified boot configuration to maximize impact.
8. Final Objective: The attacker achieves their final objective, which could include data encryption, data theft, or system disruption.

Impact

Successful modification of boot configuration data can lead to significant system instability and data loss. In ransomware attacks, this technique prevents the system from recovering, increasing the likelihood of the victim paying the ransom. While the exact number of affected organizations is unknown, this technique is widely used in ransomware campaigns and can affect any Windows system if successfully executed.

Recommendation

• Deploy the “Modification of Boot Configuration” Sigma rule to your SIEM and tune for your environment to detect the malicious use of bcdedit.exe described in this brief.
• Enable Sysmon process creation logging to capture bcdedit.exe executions and their command-line arguments (Sysmon Event ID 1).
• Investigate any detected instances of bcdedit.exe modifying boot configuration settings to determine legitimacy, as described in the rule’s “Triage and analysis” section.
• Monitor process execution logs for unexpected processes running bcdedit.exe with arguments related to disabling recovery or ignoring boot failures.

Attack Chain

1. Initial Access: An attacker gains unauthorized access to an Azure account, potentially through compromised credentials or exploiting a vulnerability in an application.
2. Privilege Escalation (Optional): The attacker escalates their privileges within the Azure environment to gain sufficient permissions to manage and delete applications.
3. Reconnaissance: The attacker identifies target applications for deletion, potentially those critical for business operations or those used for security controls.
4. Disable Monitoring (Optional): The attacker attempts to disable logging or monitoring related to application management to avoid detection.
5. Application Deletion: The attacker initiates the deletion of the targeted application using the Azure portal, Azure CLI, or PowerShell.
6. Confirmation/Hard Delete: Depending on the application’s configuration and Azure policies, the attacker may need to confirm the deletion or perform a “hard delete” to permanently remove the application.
7. Cover Tracks: The attacker attempts to remove any remaining logs or traces of their activity to hinder forensic investigation.
8. Impact: Service disruption or data loss due to the deleted application.

Impact

The deletion of an Azure application can lead to significant service disruption, data loss, and potential financial damages. The impact depends on the criticality of the deleted application and the organization’s disaster recovery capabilities. Successful deletion can interrupt business processes, impacting both internal users and external customers. It may also lead to reputational damage and compliance violations if the application handled sensitive data.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect application deletion events in Azure Activity Logs.
• Review user roles and permissions in Azure Active Directory (Entra ID) and enforce the principle of least privilege.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges.
• Enable auditing and logging for all Azure resources, including application management activities.
• Investigate any detected application deletion events promptly to determine the root cause and potential impact.
• Establish a process for reviewing and approving application deletion requests to prevent accidental or malicious deletions.

Attack Chain

1. The attacker gains initial access to the system via phishing, exploiting a vulnerability, or using compromised credentials.
2. The attacker escalates privileges to administrator level to execute wbadmin.exe.
3. The attacker executes wbadmin.exe with the delete catalog command to remove backup catalogs.
4. The attacker executes wbadmin.exe with the delete systemstatebackup command to remove system state backups.
5. The attacker may also delete shadow copies using vssadmin.exe or wmic.exe to further hinder recovery.
6. The attacker deploys ransomware or initiates other destructive actions.
7. The attacker encrypts or destroys data on the system and connected network shares.
8. The attacker demands a ransom payment for data recovery, which is complicated by the deleted backups.

Impact

Successful deletion of backup catalogs and system state backups significantly impairs an organization’s ability to recover from a ransomware attack or other destructive event. This can lead to prolonged downtime, data loss, and financial losses associated with incident response and recovery efforts. While the number of direct victims of this specific technique is difficult to quantify, the impact is typically observed in conjunction with broader ransomware campaigns affecting organizations across various sectors.

Recommendation

• Enable Sysmon process creation logging with Event ID 1 to capture wbadmin.exe executions and activate the first Sigma rule.
• Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
• Monitor Windows Security Event Logs for process creation events related to wbadmin.exe.
• Investigate any instances of wbadmin.exe executing with delete arguments.
• Review and harden account access controls to prevent unauthorized use of wbadmin.exe.

Attack Chain

1. Initial access is gained through various methods (e.g., phishing, exploitation).
2. The attacker escalates privileges to Administrator or SYSTEM.
3. The attacker uses reg.exe or PowerShell to modify registry keys.
4. The attacker targets the HKLM\Software\Policies\Microsoft\Windows NT\SystemRestore\DisableConfig registry key.
5. Alternatively, the attacker targets the HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore\DisableSR registry key.
6. The attacker sets the value of the targeted registry key to DWORD:00000001.
7. The attacker confirms the System Restore feature is disabled.
8. The attacker proceeds with further malicious activities, knowing that recovery is hindered.

Impact

Disabling System Restore can significantly impede recovery efforts following a cyber incident. Organizations may face longer downtimes and increased costs associated with manual system reimaging or advanced forensic analysis. The absence of readily available restore points can also lead to data loss if systems are severely damaged or encrypted.

Recommendation

• Deploy the Sigma rule Registry Disable System Restore to your SIEM to detect malicious attempts to disable System Restore via registry modification.
• Monitor registry modifications related to System Restore configurations, focusing on the keys \Policies\Microsoft\Windows NT\SystemRestore and \Microsoft\Windows NT\CurrentVersion\SystemRestore, and values set to DWORD (0x00000001).
• Implement strict access controls to prevent unauthorized modification of registry settings.

Attack Chain

1. An attacker gains initial access to the network (e.g., through credential theft or phishing).
2. The attacker attempts a network login to a Windows system, generating a 4624 event with logon type “Network”.
3. The system logs a successful authentication event (event ID 4624) with a network logon type.
4. The attacker identifies a privileged account, such as an administrator account or a service account with elevated permissions.
5. The attacker initiates a password reset for the privileged account.
6. A password reset event (event ID 4724) is triggered, indicating that a password has been reset.
7. The attacker leverages the reset password to maintain persistent access to the compromised account.
8. The attacker performs malicious actions using the compromised privileged account, potentially leading to data exfiltration or system compromise.

Impact

Successful password resets of privileged accounts can lead to significant security breaches. Attackers can maintain persistent access, escalate privileges, and move laterally within the network. This can result in data theft, system compromise, and disruption of services. If successful, attackers can potentially gain control over critical systems and data, leading to significant financial and reputational damage.

Recommendation

• Enable the Windows audit policies for “Audit Logon” and “Audit User Account Management” to generate the necessary events for this detection.
• Deploy the Sigma rule “Detect Remote Password Reset of Privileged Account” to your SIEM and tune it to your environment, excluding legitimate administrative accounts and processes.
• Investigate any alerts generated by the Sigma rule by reviewing the source IP address and the target account to determine if the password reset was authorized.
• Monitor for Event ID 4724 (Account Password Reset) in conjunction with network login events to identify suspicious password reset activity.
• Review and update access controls and privileged account management policies to prevent similar incidents in the future, as mentioned in the overview section.
• Create exceptions for known IT personnel or service accounts that legitimately perform remote password resets, as detailed in the false positive analysis section.

Attack Chain

1. The attacker gains initial access to the Windows host (e.g., through phishing or exploitation).
2. The attacker escalates privileges to obtain necessary permissions to terminate processes and services.
3. The attacker uses net.exe to stop specific services, such as backup solutions or security software.
4. The attacker employs sc.exe to delete services, preventing them from restarting automatically.
5. The attacker utilizes taskkill.exe with flags like /F, /IM, or /PID to forcefully terminate processes.
6. The attacker repeats these steps, rapidly terminating multiple processes and services.
7. The attacker prepares the system for ransomware deployment by disabling security measures.
8. The attacker deploys ransomware, encrypting data and demanding a ransom for its recovery.

Impact

Successful exploitation leads to disruption of critical services, disabling of security controls, and potential data loss. If an attacker successfully terminates security solutions, they can significantly increase the likelihood of successful ransomware deployment or data exfiltration. The impact can range from temporary service outages to complete system compromise and data encryption, resulting in financial losses, reputational damage, and operational disruption.

Recommendation

• Deploy the High Number of Process Terminations via Taskkill and High Number of Service Terminations via SC Sigma rules to your SIEM and tune for your environment.
• Investigate any alerts triggered by the rules, focusing on the processes terminated and the user accounts involved.
• Enable process creation logging with command-line arguments to ensure the rules have sufficient data to function effectively.
• Review the references provided to understand attacker techniques and improve detection strategies.
• Implement network segmentation to limit the lateral movement of attackers.
• Regularly review and update security policies to prevent unauthorized process termination.