Attack Chain

1. An attacker gains initial access to a system through various means (e.g., compromised credentials, phishing).
2. The attacker elevates privileges to gain necessary permissions to modify service configurations.
3. The attacker executes sc.exe with the sdset command to modify the DACL of a targeted service.
4. The sdset command arguments specify the new security descriptor, denying access to specific user groups (e.g., IU, SU, BA, SY, WD).
5. The service becomes inaccessible to the targeted user groups, potentially disrupting legitimate operations or security tools.
6. The attacker may repeat this process for multiple services to further impair system functionality or evade detection.
7. The attacker leverages the disabled or hidden services to maintain persistence or carry out other malicious activities.

Impact

Successful modification of service DACLs can lead to a denial-of-service condition for legitimate users and system administrators. This can impair the functionality of critical security tools, hinder incident response efforts, and provide attackers with a persistent foothold on the compromised system. The hiding of services can also prevent users from identifying and removing malicious services. While the number of victims is not specified in the source, organizations across various sectors are potentially vulnerable to this type of attack.

Recommendation

• Deploy the Sigma rule Service DACL Modification via sc.exe to your SIEM to detect this specific behavior.
• Enable Sysmon process creation logging to provide the necessary data for the Sigma rule to function effectively.
• Investigate any instances where sc.exe is used with the sdset argument and access denial flags, focusing on the targeted user groups (IU, SU, BA, SY, WD).
• Implement strict access controls and monitor for unauthorized attempts to modify service configurations.
• Regularly audit service permissions to identify and remediate any unauthorized changes.
• Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations.

Attack Chain

1. The attacker gains initial access to an account with sufficient privileges to modify Active Directory objects (e.g., Domain Admin).
2. The attacker uses AD management tools (PowerShell, ADSI Edit, etc.) to target a specific user or computer account.
3. The attacker modifies the nTSecurityDescriptor attribute of the targeted account.
4. The attacker grants replication rights to the targeted account by adding specific Access Control Entries (ACEs) containing the GUIDs 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, and 89e95b76-444d-4c62-991a-0facbeda640c.
5. The attacker uses the DCSync technique, impersonating a domain controller, to request password hashes.
6. The Active Directory server, believing the request is legitimate due to the granted replication rights, provides the attacker with the requested credential information.
7. The attacker obtains password hashes for domain users and computers.
8. The attacker uses the obtained credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows attackers to compromise the entire Active Directory domain by gaining access to sensitive credential data. This could lead to complete control over the network, including access to critical systems, sensitive data, and the ability to disrupt business operations. The modification of security descriptors creates a persistent backdoor that can be used repeatedly to harvest credentials.

Recommendation

• Enable Audit Directory Service Changes to generate the necessary event logs for detection (https://ela.st/audit-directory-service-changes).
• Deploy the Sigma rule provided below to detect unauthorized modifications to the nTSecurityDescriptor attribute. Tune the rule to exclude legitimate administrative accounts or scripts that may perform authorized modifications.
• Monitor Windows Security Event Logs (event code 5136) for changes to the nTSecurityDescriptor attribute and investigate any unexpected modifications, focusing on the presence of DCSync-related GUIDs.
• Regularly review and audit Active Directory permissions, focusing on accounts with replication rights, to ensure they are legitimate and necessary.

Attack Chain

1. The attacker gains initial access to a system through an exploit, such as phishing or exploiting a vulnerability.
2. The attacker obtains local administrator credentials on the compromised system.
3. The attacker modifies the LocalAccountTokenFilterPolicy registry key to a value of 1. This is done to allow remote connections from local administrator accounts to receive high-integrity tokens. The registry key is typically located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
4. The attacker leverages a “pass the hash” attack (T1550.002) using the compromised local administrator credentials.
5. The attacker attempts to move laterally to other systems within the network using the “pass the hash” technique and the modified LocalAccountTokenFilterPolicy.
6. Due to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.
7. The attacker bypasses UAC on the remote system, gaining elevated privileges.
8. The attacker performs malicious activities on the remote system, such as data exfiltration or deploying ransomware.

Impact

Successful modification of the LocalAccountTokenFilterPolicy allows attackers to bypass User Account Control (UAC) and gain elevated privileges on remote systems, potentially leading to unauthorized access to sensitive data, lateral movement across the network, and the deployment of ransomware. The overall impact can include data breaches, financial loss, and reputational damage.

Recommendation

• Deploy the Sigma rule Local Account TokenFilter Policy Enabled to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.
• Enable Sysmon registry event logging to capture modifications to the registry, which is required for the Local Account TokenFilter Policy Enabled Sigma rule.
• Review the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.
• Monitor registry events for changes to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy path, specifically looking for changes to the value data.

Attack Chain

1. Initial compromise of a system through an unrelated vulnerability or social engineering.
2. Installation or execution of a GenAI tool (e.g., ollama, lmstudio) on the compromised system.
3. The GenAI tool is configured or instructed to scan the file system for sensitive files.
4. The GenAI tool accesses files containing credentials, such as .aws/credentials, browser password databases (Login Data, key3.db), or SSH keys (.ssh/id_*).
5. The GenAI tool exfiltrates the harvested credentials and API keys to a remote server controlled by the attacker.
6. The attacker uses the stolen credentials to gain unauthorized access to cloud resources, internal systems, or other sensitive accounts.
7. The GenAI tool attempts to modify shell configuration files (e.g., .bashrc, .zshrc) to establish persistence.
8. Upon system restart or user login, the modified shell configuration executes malicious commands, granting the attacker persistent access.

Impact

Successful exploitation of this threat can lead to significant data breaches, unauthorized access to critical systems, and persistent compromise of affected environments. Attackers can leverage stolen credentials to escalate privileges, move laterally within the network, and exfiltrate sensitive data. The number of victims and sectors targeted are currently unknown, but the potential impact is widespread given the increasing adoption of GenAI tools in various industries. Credential theft leads to financial loss, intellectual property theft, and reputational damage.

Recommendation

• Deploy the Sigma rule “GenAI Process Accessing Sensitive Files” to your SIEM to detect GenAI tools accessing sensitive files on endpoints.
• Enable file access monitoring on systems where GenAI tools are used to capture access events for analysis.
• Review and restrict the use of GenAI tools within the environment, especially concerning access to sensitive file paths.
• Monitor for modifications to shell configuration files (e.g., .bashrc, .zshrc, .profile) as an indicator of persistence attempts.
• Implement regular credential rotation policies to minimize the impact of stolen credentials.

Attack Chain

1. An attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.
2. The attacker leverages the Lambda function’s execution role, which has excessive IAM permissions.
3. The attacker executes IAM API calls, such as CreateUser, CreateRole, or CreateAccessKey, to create new IAM identities.
4. The attacker uses AttachUserPolicy, PutUserPolicy, AttachRolePolicy, or PutRolePolicy to grant elevated permissions to the newly created or existing IAM identities.
5. The attacker modifies instance profiles using CreateInstanceProfile and AddRoleToInstanceProfile to prepare EC2 instances for lateral movement.
6. The attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via sts:AssumeRole.
7. The attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.
8. The attacker establishes persistence by creating rogue IAM users, roles, or access keys.

Impact

A successful attack can lead to full compromise of the AWS environment. An attacker could create highly privileged IAM users and roles, granting them the ability to access and control all AWS resources. This can result in data breaches, service disruptions, and financial losses. The impact is magnified in environments where Lambda functions are heavily relied upon for critical business operations.

Recommendation

• Deploy the Sigma rule “AWS IAM Sensitive Operations via Lambda Execution Role” to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.
• Review and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.
• Monitor aws.cloudtrail.user_identity.arn to identify the Lambda function and associated deployment path responsible for the IAM API calls.
• Investigate aws.cloudtrail.request_parameters for targets such as userName, groupName, roleName, policyArn, or instanceProfileName to understand the scope of the IAM operations.
• Revoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.
• Remediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.

Attack Chain

1. Initial Access: An attacker attempts to log into a Google Workspace account using compromised or brute-forced credentials.
2. Login Attempt: The login attempt triggers a “gov_attack_warning” within Google Workspace, indicating a potential government-backed threat actor.
3. Privilege Escalation (Potential): If the compromised account has elevated privileges, the attacker may attempt to escalate privileges within the Google Workspace environment.
4. Defense Evasion (Potential): The attacker may attempt to disable security features or modify audit logs to evade detection.
5. Persistence (Potential): The attacker may establish persistent access through methods such as creating rogue apps or modifying account settings.
6. Data Access: The attacker gains access to sensitive data stored within Google Workspace, such as documents, emails, and files.
7. Exfiltration (Potential): The attacker exfiltrates the stolen data to an external location.
8. Impact: The organization suffers a data breach, reputational damage, and potential financial losses.

Impact

A successful attack could lead to the compromise of sensitive data within the Google Workspace environment, including confidential documents, emails, and other business-critical information. The potential consequences range from reputational damage and legal liabilities to financial losses and disruption of business operations. The number of affected users and the severity of the impact will depend on the scope of the attacker’s access and the sensitivity of the compromised data.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect “gov_attack_warning” events in Google Workspace logs.
• Investigate any triggered alerts promptly, focusing on the affected user account and associated activity.
• Review the Google Workspace audit logs for any suspicious activity leading up to the “gov_attack_warning” event.
• Implement multi-factor authentication (MFA) for all Google Workspace accounts, especially those with elevated privileges.
• Monitor Google Workspace activity logs for suspicious patterns, such as unusual login locations, failed login attempts, and changes to account settings.

Attack Chain

1. Attacker gains initial access to a system via phishing or exploiting a software vulnerability.
2. Attacker installs or deploys a GenAI tool (e.g., LM Studio, Claude, Copilot) on the compromised system.
3. The attacker configures the GenAI tool to scan the file system for specific file names and patterns associated with sensitive data (credentials, keys, cookies).
4. The GenAI tool accesses files such as .aws/credentials, .ssh/id_rsa, browser login databases (e.g., Login Data, logins.json, Cookies), and other credential stores.
5. The GenAI tool may modify shell configuration files (.bashrc, .zshrc) to establish persistence.
6. The GenAI tool stages the collected data for exfiltration.
7. The attacker exfiltrates the harvested credentials and data to an external server.
8. The attacker uses the stolen credentials to gain unauthorized access to other systems or cloud resources.

Impact

Successful exploitation can lead to widespread credential compromise, allowing attackers to move laterally within a network, access sensitive data, and potentially disrupt critical business operations. A single compromised developer workstation could expose cloud infrastructure credentials, impacting hundreds of systems and services. The use of GenAI tools allows for rapid and automated credential harvesting, significantly increasing the scale and speed of potential breaches. Sectors at high risk include software development, cloud computing, and any organization that relies heavily on API keys and secrets for authentication.

Recommendation

• Deploy the Sigma rule GenAI Process Accessing Sensitive Files to your SIEM to detect GenAI tools accessing sensitive files. Tune for your environment to reduce false positives.
• Monitor file access events, specifically looking for GenAI processes (ollama, lmstudio, claude) accessing files with names like credentials, id_rsa, logins.json, and .bashrc, as outlined in the Sigma rule.
• Implement stricter access controls and monitoring for sensitive directories like .aws, .ssh, and browser profile directories.
• Regularly audit and rotate credentials, API keys, and tokens, especially those stored in files.
• Educate developers and users about the risks of using GenAI tools to handle sensitive data.

Attack Chain

1. Vulnerability Exploitation (Initial Access): Actors exploit vulnerabilities in networking devices and widely used software, leveraging both newly disclosed and unpatched flaws.
2. Social Engineering (Initial Access): North Korean actors use fake recruiter personas via campaigns like Contagious Interview to trick targets into executing code or handing over credentials.
3. Credential Harvesting (Privilege Escalation/Persistence): After initial access, actors harvest credentials to gain further access within the network.
4. Web Shell Deployment (Persistence): Chinese actors deploy web shells for persistent access to compromised systems.
5. Custom Backdoor Installation (Persistence): Backdoors, including compact custom backdoors like those used by ShroudedSnooper, are deployed to maintain long-term access.
6. Tunneling (Command & Control): Actors use tunneling tools to maintain covert communication channels with compromised systems.
7. Data Exfiltration (Exfiltration): Actors exfiltrate sensitive data, including espionage-related information or financial data such as cryptocurrency.
8. Disruption/Espionage (Impact): Depending on the actor and objective, the final stage involves disruptive activities like DDoS attacks or long-term espionage.

Impact

The observed state-sponsored activity resulted in significant financial losses, espionage, and disruptive attacks. North Korean actors stole $1.5 billion in cryptocurrency and generated billions in revenue through fraudulent IT work, impacting financial institutions and various Fortune 500 companies. Iranian hacktivist operations caused disruption through DDoS attacks and defacements. Espionage campaigns targeted sectors such as telecommunications, potentially compromising sensitive communications and intellectual property. The persistent nature of these attacks allows for long-term monitoring and potential future exploitation.

Recommendation

• Prioritize patching of both newly disclosed and long-standing vulnerabilities in networking devices and software to mitigate initial access (Reference: Overview, Attack Chain Step 1).
• Implement robust identity and access management controls, including multi-factor authentication and monitoring for suspicious login activity, to counter social engineering and credential-based attacks (Reference: Attack Chain Step 2 & 3).
• Increase visibility into network and edge infrastructure by enabling comprehensive logging and monitoring to detect unauthorized access and persistence mechanisms (Reference: Attack Chain Steps 4, 5, & 6).
• Deploy the Sigma rules below to detect suspicious web shell activity and backdoor installations (Reference: Rules).
• Monitor network traffic for unusual patterns and connections indicative of tunneling or data exfiltration (Reference: Attack Chain Steps 6 & 7).

Attack Chain

1. An attacker gains initial access to a system via an exploit or social engineering.
2. The attacker uses MSHTA.exe to execute malicious HTML Application code.
3. MSHTA.exe is used to launch a PowerShell script.
4. The PowerShell script uses the Registry module to add a new registry key.
5. The registry key is configured to execute a payload upon system startup.
6. The attacker uses wscript.exe or cscript.exe to execute VBScript or JScript.
7. The script modifies registry values to disable security features.
8. The compromised system restarts, executing the payload defined in the registry, granting the attacker persistent access.

Impact

Successful exploitation allows attackers to establish persistence on the targeted system, enabling them to maintain access even after a reboot. This can lead to data theft, further malware deployment, or complete system compromise. The impact ranges from minor data breaches to significant operational disruptions. The scope of the impact depends on the attacker’s objectives and the compromised system’s role within the organization.

Recommendation

• Deploy the Sigma rule “Registry Tampering by Potentially Suspicious Processes” to your SIEM to detect this specific activity, and tune for your environment (rules).
• Investigate any instances of wscript.exe, cscript.exe or mshta.exe modifying registry keys outside of known-good paths (rules).
• Monitor registry events for unexpected modifications by scripting engines, focusing on persistence-related keys (rules).

Attack Chain

1. Attacker compromises user credentials through phishing or other means.
2. Attacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.
3. The Microsoft Authentication Broker is used to request an access token.
4. The request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.
5. The OAuth scope includes adrs_access, indicating an attempt to access ADRS functionalities.
6. The request is made using a refresh token, suggesting an attempt to establish persistent access.
7. Successful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).
8. The attacker uses the PRT or device registration to maintain unauthorized access to resources.

Impact

Successful exploitation could allow an attacker to maintain persistent access to an organization’s cloud resources, even after a user changes their password or is removed from the organization. This can lead to data exfiltration, lateral movement, and further compromise of sensitive information. The number of potentially affected users depends on the scope of the initial compromise and the effectiveness of the attacker’s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.

Recommendation

• Deploy the Sigma rule “Entra ID ADRS Token Request by Microsoft Authentication Broker” to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.
• Investigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.
• Review Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.
• Monitor Entra ID audit logs for device registrations or changes to user’s device registration status as suggested in the rule’s triage steps.
• Correlate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule’s triage.
• Consider adjusting the rule or adding exceptions for specific applications or user accounts that legitimately require access to the Device Registration Service, based on false positive analysis.

Attack Chain

1. An attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.
2. The attacker executes the AssumeRoot API call to assume the privileges of the root user.
3. The attacker uses the CreateLoginProfile API call without specifying a userName. This action creates a console login profile directly for the root account instead of an IAM user. The aws.cloudtrail.request_parameters will not contain userName=.
4. The attacker sets a password for the root account using the CreateLoginProfile API. passwordResetRequired might be set to true or omitted, with omission potentially indicating an attacker-controlled password.
5. The attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a ConsoleLogin event.
6. The attacker uses the root account’s privileges to create or modify resources, escalate privileges, or exfiltrate data.
7. The attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.
8. The attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.

Impact

A successful attack can lead to complete control over the AWS environment. The attacker can create, modify, or delete resources; access sensitive data; and disrupt services. Because the root user has unrestricted privileges, the impact is extremely high. There have been no reported victim counts. However, any successful exploitation can have severe impacts including data breaches, financial loss, and reputational damage.

Recommendation

• Deploy the Sigma rule “AWS IAM Login Profile Added for Root” to detect unauthorized creation of login profiles for the root account and tune for your environment.
• Investigate any CreateLoginProfile events where aws.cloudtrail.user_identity.type is Root and aws.cloudtrail.request_parameters does not contain userName=.
• Enable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.
• Review IAM policies for least-privilege adherence, focusing on iam:CreateLoginProfile, iam:UpdateLoginProfile, and iam:CreateAccessKey permissions.

Attack Chain

1. The attacker gains initial access to the macOS system through methods such as exploiting vulnerabilities, social engineering, or phishing.
2. The attacker achieves code execution within a Python process. This can occur via a malicious script, a compromised Python package, or by exploiting deserialization vulnerabilities like pickle.load or torch.load.
3. The malicious Python script crafts a LaunchAgent or LaunchDaemon plist file. This plist file contains configuration details about the program to be executed, including its path, arguments, and execution triggers.
4. The Python process writes the crafted plist file to either the /Library/LaunchAgents/ (for user-level persistence) or /Library/LaunchDaemons/ (for system-level persistence) directory.
5. The LaunchAgent or LaunchDaemon is automatically loaded by launchd at login or boot, according to the configuration specified in the plist file.
6. The program specified in the plist file is executed, giving the attacker persistent access to the compromised system.
7. The attacker can then use this persistent access to perform various malicious activities, such as data exfiltration, lateral movement, or deploying additional malware.

Impact

A successful attack can lead to persistent compromise of macOS systems. Attackers can maintain unauthorized access, execute arbitrary code, steal sensitive data, or use the compromised system as a foothold for further attacks within the network. The impact can range from individual user data theft to widespread organizational breaches, depending on the attacker’s objectives and the system’s role within the network.

Recommendation

• Deploy the Sigma rule “Detect Python Launch Agent/Daemon Creation” to your SIEM to identify when a Python process creates a LaunchAgent or LaunchDaemon plist file.
• Enable Elastic Defend endpoint logging to capture event.action:"launch_daemon" events, which are necessary for the Sigma rule to function correctly.
• Prioritize investigation of alerts generated by the Sigma rule, focusing on understanding the program arguments, run-at-load configuration, and keep-alive settings within the created plist file.
• Implement strict dependency management and vulnerability scanning for Python environments to prevent the use of compromised packages.
• Monitor for processes loading model files (torch.load, pickle.load) and investigate any suspicious activity to prevent exploitation of deserialization vulnerabilities.

Attack Chain

1. An authenticated user with upload privileges logs into the code-marketplace application.
2. The attacker crafts a malicious VSIX file containing zip entries with path traversal sequences (e.g., “../../../etc/cron.d/evil”).
3. The attacker uploads the malicious VSIX file through the application’s extension upload functionality.
4. The ExtractZip function processes the uploaded VSIX file without proper sanitization of zip entry names.
5. The filepath.Join function constructs the output path using the unsanitized zip entry name and a base directory.
6. Path traversal sequences like .. are resolved by filepath.Clean, but the resulting path is not checked against the intended base directory, allowing it to escape.
7. The application writes the extracted file to an attacker-controlled location on the server’s file system.
8. The attacker achieves persistence, privilege escalation, or arbitrary code execution by overwriting critical system files or injecting malicious code into system configurations like cron jobs or SSH authorized keys.

Impact

Successful exploitation of this Zip Slip vulnerability allows attackers to write arbitrary files to the underlying system. An attacker can achieve persistence by injecting malicious cron jobs or modifying system initialization scripts. Privilege escalation is possible via SSH key injection or by overwriting binaries with malicious versions. The impact ranges from system compromise to data exfiltration and denial of service. While the number of victims is unknown, any organization using vulnerable versions of the Coder code-marketplace application is at risk.

Recommendation

• Upgrade the coder/code-marketplace application to version 2.4.2 or later to remediate CVE-2026-35454.
• Implement file integrity monitoring on critical system directories (e.g., /etc/cron.d, /root/.ssh) using a file_event log source to detect unauthorized file modifications.
• Deploy the Sigma rule “Detect Suspicious File Creation in Sensitive Directories” to detect potential exploitation attempts based on file creation events.
• Enable webserver logging and deploy the provided Sigma rule “Detect VSIX Uploads with Path Traversal” to identify suspicious VSIX uploads containing path traversal sequences based on request parameters.

Attack Chain

1. Initial Access: The attacker gains initial access to the vSphere environment, potentially through compromised credentials or vulnerabilities in externally facing services.
2. VCSA Compromise: The attacker targets the vCenter Server Appliance (VCSA) to gain centralized control over the vSphere environment.
3. Privilege Escalation: The attacker escalates privileges within the VCSA to gain root or administrative access to the underlying Photon Linux OS.
4. Persistence: The attacker establishes persistence by modifying system files or creating malicious services that survive reboots. This may involve writing scripts to /etc/rc.local.d or modifying startup files.
5. Lateral Movement: The attacker uses the compromised VCSA to move laterally to other ESXi hosts and virtual machines within the environment.
6. Data Access: The attacker accesses the underlying storage (VMDKs) of virtual machines, bypassing operating system permissions and traditional file system security, to exfiltrate sensitive data.
7. Control of ESXi Hosts: The attacker resets root credentials on any managed ESXi host, providing full control of the hypervisor.
8. Impact: The attacker can power off, delete, or reconfigure any virtual machine, encrypt datastores, disable virtual networks, and exfiltrate data. The ultimate objective could be data theft, disruption of services, or ransomware deployment.

Impact

A successful BRICKSTORM attack can have severe consequences, including complete compromise of the vSphere environment. This can lead to data exfiltration of Tier-0 assets, disruption of critical services (such as domain controllers), and potential ransomware deployment across all virtual machines. Organizations may face significant financial losses, reputational damage, and legal liabilities. The lack of command-line logging on the Photon OS shell further hinders incident response efforts.

Recommendation

• Harden the vCenter Server Appliance (VCSA) by implementing the security configurations recommended in the Mandiant vCenter Hardening Script (reference: vCenter Hardening Script link in Overview).
• Implement logging and monitoring for the Photon OS shell to detect unauthorized access and command execution (reference: Phase 4 in Content).
• Upgrade to a supported version of vSphere to receive critical security patches (reference: vSphere 7 End of Life in Content).
• Enable Secure Boot, strictly firewall management interfaces, and disable shell access on ESXi hosts and the VCSA (reference: Technical Hardening in Content).
• Deploy the Sigma rule to detect modifications to startup files for persistence on Photon OS (reference: Sigma rule: “Detect Startup File Modification in Photon OS”).

Attack Chain

1. An attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.
2. The attacker executes commands within the container to locate the SSH authorized_keys file (typically located at /home/<user>/.ssh/authorized_keys or /root/.ssh/authorized_keys).
3. The attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like echo "ssh-rsa AAAAB3Nz..." >> /root/.ssh/authorized_keys.
4. The attacker uses the newly added SSH key to authenticate and log into the container without needing a password.
5. The attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.
6. The attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.

Impact

Successful modification of the authorized_keys file enables persistent, unauthorized SSH access to the compromised container. This can lead to lateral movement within the container environment, privilege escalation, data exfiltration, or further attacks on other systems. The rule aims to detect these modifications early, preventing significant damage. While the number of specific victims isn’t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: SSH Authorized Key File Activity).
• Enable Elastic Defend for Containers integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.
• Investigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule’s description (rule: SSH Authorized Key File Activity).
• Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.
• Create exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.

Attack Chain

1. Initial Access: An attacker gains initial access to a system with sufficient privileges to execute PowerShell scripts, possibly through compromised credentials or other initial access vectors (T1078.002).
2. Discovery: The attacker uses PowerShell to enumerate existing dMSAs and their associated msDS-ManagedAccountPrecededByLink attributes.
3. Attribute Modification: The attacker crafts a PowerShell script to modify the msDS-ManagedAccountPrecededByLink attribute of a target dMSA. This involves using the .Put("msDS-ManagedAccountPrecededByLink" command and specifying a new distinguished name (CN=) for the preceding account.
4. Persistence: The attacker leverages the modified dMSA link to establish a persistent foothold in the environment by gaining control over the targeted dMSA.
5. Privilege Escalation: By manipulating the dMSA links, the attacker effectively inherits the permissions and privileges associated with the compromised dMSA, thereby escalating their own privileges.
6. Defense Evasion: The attacker may attempt to evade detection by obfuscating the PowerShell script or using other techniques to hide their activity.
7. Lateral Movement: With elevated privileges, the attacker can move laterally within the network, accessing sensitive resources and systems.

Impact

Successful exploitation of the ‘BadSuccessor’ vulnerability through modification of the msDS-ManagedAccountPrecededByLink attribute can lead to complete domain compromise. An attacker can gain control over critical services and data, potentially resulting in data breaches, service disruptions, and significant financial losses. The impact is amplified in environments heavily reliant on Active Directory for authentication and authorization.

Recommendation

• Deploy the provided Sigma rule to your SIEM and tune for your environment to detect potentially malicious modifications to dMSA link attributes via PowerShell (logsource: ps_script, product: windows).
• Investigate any alerts triggered by the Sigma rule to determine if the activity is legitimate or indicative of an attempted exploitation of the ‘BadSuccessor’ vulnerability.
• Implement strict access controls and monitoring for systems and accounts with the ability to modify Active Directory attributes.
• Review and harden Active Directory security configurations to prevent unauthorized modification of sensitive attributes.

Attack Chain

1. An attacker gains control over the saveTo or output parameter of the vulnerable functions. This could be achieved through a malicious application, supply chain attack, or other means of code injection.
2. The attacker crafts a path containing traversal sequences (e.g., ../) designed to navigate outside of the intended save directory.
3. The attacker calls the mobile_save_screenshot or mobile_start_screen_recording tool with the manipulated path as the saveTo or output parameter, respectively.
4. The vulnerable function passes the attacker-controlled path to fs.writeFileSync() without validation.
5. fs.writeFileSync() writes the screenshot or screen recording data to the attacker-specified path.
6. If the path leads to a sensitive system file (e.g., ~/.bashrc, ~/.ssh/authorized_keys), it is overwritten with the contents of the screenshot or screen recording.
7. The attacker can overwrite configuration files or executables in order to achieve code execution.
8. The attacker achieves persistence and/or elevated privileges on the system.

Impact

Successful exploitation of this path traversal vulnerability can have severe consequences. An attacker can overwrite critical system files, such as shell configuration files (.bashrc, .zshrc), SSH authorized keys (.ssh/authorized_keys), or application configuration files. This can lead to arbitrary code execution, privilege escalation, and persistent backdoor access to the affected system. The reported impact includes potential for a broken shell and unauthorized access. All users of @mobilenext/mobile-mcp versions prior to 0.0.49 are vulnerable.

Recommendation

• Upgrade to @mobilenext/mobile-mcp version 0.0.49 or later to remediate the vulnerability.
• Implement robust input validation for all file paths used in file system operations. Specifically, validate the saveTo and output parameters of the mobile_save_screenshot and mobile_start_screen_recording functions.
• Deploy the Sigma rule “Detect Mobile-MCP Path Traversal Attempts” to your SIEM to detect attempts to exploit this vulnerability.
• Monitor application logs for unusual file access patterns or attempts to write to sensitive system directories.

Attack Chain

1. The attacker gains initial access to the agent workspace.
2. The attacker plants a symbolic link named IDENTITY.md within the agent workspace. This symlink points to a sensitive system file, such as /etc/crontab or ~/.ssh/authorized_keys.
3. The ensureAgentWorkspace function is called, but the exclusive-create flag (wx) skips creation due to the existing symlink (EEXIST error).
4. The attacker triggers the agents.create or agents.update API endpoint, for example, by sending an HTTP POST request.
5. The agents.create or agents.update handler constructs the path to IDENTITY.md using path.join(workspaceDir, DEFAULT_IDENTITY_FILENAME).
6. The vulnerable fs.appendFile function is called to append agent metadata (name, emoji, avatar) to the IDENTITY.md file. Because fs.appendFile follows symlinks, the content is written to the attacker-controlled target file.
7. Attacker-controlled data is appended to the target file.
8. If the target file is a cron configuration file, this leads to remote code execution. If it’s an SSH authorized_keys file, this leads to unauthorized access.

Impact

Successful exploitation allows an attacker to append attacker-controlled content to arbitrary files on the system. This can lead to:

• Remote Code Execution: By appending malicious entries to /etc/crontab or user crontab files.
• Persistent Code Execution: By modifying shell configuration files like ~/.bashrc or ~/.profile.
• Unauthorized SSH Access: By appending SSH keys to ~/.ssh/authorized_keys.
• Service Disruption: By modifying application configuration files.

The vulnerability affects openclaw versions 2026.2.22 and earlier, and no patches are currently available. The number of affected systems depends on the adoption rate of the openclaw package.

Recommendation

• Monitor file creation events within agent workspace directories for the creation of symbolic links using file_event logs.
• Implement and deploy the provided Sigma rule to detect exploitation attempts by monitoring fs.appendFile calls related to IDENTITY.md without symlink resolution.
• Restrict access to the agent workspace directory to prevent attackers from planting symlinks.
• Upgrade to a patched version of openclaw when available.

Attack Chain

1. An unprivileged user initiates the ATConfig mechanism within the Windows Accessibility features.
2. The exploit creates a registry symlink pointing to a protected HKLM key.
3. A race condition is triggered during the ATConfig process, allowing the exploit to bypass security checks.
4. The attacker leverages this race condition to overwrite the target HKLM registry key with arbitrary data.
5. The modified registry key is used to establish persistence, for example, by creating a Run key.
6. Upon system restart or user login, the malicious payload associated with the modified Run key is executed.
7. The attacker gains elevated privileges by executing code within the context of a privileged process.

Impact

Successful exploitation of RegPwnBOF allows an attacker to gain persistent access to a compromised system and escalate their privileges to administrator level. This can lead to complete system compromise, data theft, and the installation of malware. The impact is magnified by the fact that this exploit can be triggered by a normal user, bypassing traditional access controls. The number of potential victims is considerable, as the vulnerability exists within the Windows Accessibility features, which are enabled by default on many systems.

Recommendation

• Monitor registry modifications targeting HKLM keys, especially those related to Accessibility features, using a process_creation log source and the provided Sigma rules.
• Implement strict access controls and least-privilege principles to limit the ability of unprivileged users to interact with system-level configurations.
• Investigate any unusual registry symlink creation events using file_event logs, particularly those involving the ATConfig mechanism, to identify potential RegPwnBOF exploitation attempts.

Attack Chain

1. An attacker compromises an Entra ID account with sufficient privileges to modify application registrations.
2. The attacker navigates to the Entra ID portal or uses PowerShell/Azure CLI to locate a target application with federated identity credentials configured.
3. The attacker modifies the “Issuer” URL of an existing Federated Identity Credential within the application registration. They replace the legitimate issuer URL with a URL controlled by the attacker.
4. The attacker configures their own identity provider to issue tokens that match the application’s expected audience and subject claims.
5. The attacker crafts a malicious token from their identity provider, impersonating the legitimate service principal.
6. The attacker uses the crafted token to authenticate to Azure resources, bypassing normal authentication controls.
7. The attacker leverages the application’s permissions to access sensitive data, modify configurations, or deploy malicious code.
8. The attacker maintains persistent access to the Azure environment by continuing to use the compromised federated identity configuration.

Impact

Successful exploitation allows an attacker to gain persistent access to Azure resources with the permissions of the compromised application. This could lead to data breaches, unauthorized modifications to critical infrastructure, and deployment of malicious code within the cloud environment. The impact is significant because it bypasses traditional authentication methods and relies on a trust relationship established with an external identity provider. The rule is rated high severity because it directly addresses a persistence and privilege escalation technique that can severely impact the confidentiality, integrity, and availability of cloud resources.

Recommendation

• Enable the Azure integration with Microsoft Entra ID Audit Logs data stream to ingest data in your Elastic Stack deployment, as required by the rule setup instructions.
• Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications to federated identity credential issuers in Entra ID (Entra ID Federated Identity Credential Issuer Modified).
• Review azure.auditlogs.properties.initiated_by.user.userPrincipalName and ipAddress logs to determine the source of detected changes, as recommended in the rule’s triage notes.
• Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations within Entra ID, as suggested in the rule’s response and remediation guidance.

Attack Chain

1. Initial Compromise: An attacker gains initial access to a Linux system through methods such as exploiting vulnerabilities or using stolen credentials.
2. Privilege Escalation: Once inside, the attacker attempts to escalate privileges to gain root access using exploits or misconfigurations.
3. Persistence Establishment: The attacker employs various Linux persistence mechanisms to ensure continued access to the compromised system. These techniques include manipulating init scripts, cron jobs, and systemd services.
4. Init Script Modification: The attacker modifies init scripts located in /etc/init.d/ or /etc/rc.d/ to execute malicious code during system startup.
5. Cron Job Manipulation: The attacker schedules malicious tasks using cron jobs by adding entries to /etc/crontab or user-specific crontab files.
6. Systemd Service Modification: The attacker creates or modifies systemd service files in /etc/systemd/system/ to execute malicious code as a service.
7. Reverse Shell Installation: The attacker installs a reverse shell to maintain persistent access by connecting back to an attacker-controlled server. This may involve techniques like download-execute or obfuscation.
8. Data Exfiltration/Malicious Activity: With persistent access established, the attacker proceeds to exfiltrate sensitive data, deploy ransomware, or perform other malicious activities.

Impact

Successful exploitation and persistence within a Linux environment can allow attackers to maintain long-term access, leading to data theft, system disruption, or the deployment of ransomware. The impact can range from data breaches and financial losses to reputational damage and operational downtime. The scope of impact depends on the level of access gained and the attacker’s objectives.

Recommendation

• Deploy the Sigma rule for detecting init script modifications to identify potential persistence attempts (reference: Sigma rule for init script modification).
• Deploy the Sigma rule for detecting cron job modifications to identify potential persistence attempts (reference: Sigma rule for cron job modification).
• Regularly audit systemd service configurations for unauthorized modifications using the Sigma rule (reference: Sigma rule for systemd service modification).
• Use Persistnux or similar tools to regularly scan systems for known persistence mechanisms and review the generated reports (reference: Persistnux tool).

Attack Chain

1. An attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.
2. The attacker attempts to create a new ClusterRole or Role with broad permissions, including wildcard verbs and resources.
3. The attacker may use kubectl or a similar tool to apply a YAML manifest defining the malicious role.
4. The Kubernetes API server receives the request to create the role, and the audit logging system captures the event.
5. The attacker then attempts to bind the newly created role to a service account or user, granting them the elevated permissions. This is achieved by creating or modifying a RoleBinding or ClusterRoleBinding object.
6. The Kubernetes API server logs the creation or modification of the RoleBinding or ClusterRoleBinding.
7. With the elevated permissions, the attacker can now perform actions they were previously unauthorized to do, such as accessing sensitive data, deploying malicious containers, or modifying cluster configurations.
8. The attacker leverages these elevated privileges to establish persistence within the cluster and potentially move laterally to other resources or environments.

Impact

A successful attack can lead to full cluster compromise, allowing the attacker to control all resources and data within the Kubernetes environment. This can result in data breaches, service disruptions, and significant financial losses. The severity depends on the scope of the compromised role and the resources it grants access to. Even seemingly minor modifications can have a cascading effect, enabling attackers to gain complete control over critical systems.

Recommendation

• Deploy the Sigma rule “Kubernetes Creation or Modification of Sensitive Role” to your SIEM and tune it for your environment to detect suspicious RBAC changes (rule.name).
• Monitor Kubernetes audit logs for the creation or modification of Roles and ClusterRoles with wildcard permissions or escalation verbs (kubernetes.audit.requestObject.rules.verbs, kubernetes.audit.requestObject.rules.resources).
• Implement RBAC guardrails, such as OPA Gatekeeper or Kyverno policies, to prevent the creation of overly permissive roles (references).
• Restrict who can create or update RBAC objects and require all RBAC changes to go through code review and signed GitOps automation (references).
• Regularly review existing Roles and ClusterRoles to identify and remove any unnecessary or overly broad permissions.
• Enable Sysmon process creation logging on nodes to enhance detection capabilities around kubectl usage.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.
2. The attacker attempts to enumerate existing EC2 instances to identify potential targets.
3. The attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.
4. The attacker uses the ImportKeyPair API call within the EC2 service to import the generated or obtained SSH key pair.
5. The attacker modifies the EC2 instance’s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.
6. The attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.
7. Once inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.
8. The attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.

Impact

A successful key pair import can lead to complete compromise of the affected EC2 instances, potentially impacting dozens of servers depending on the environment. Sensitive data stored on or accessible from these instances could be exfiltrated, leading to financial loss, reputational damage, and regulatory fines. Furthermore, compromised instances can be used as a launchpad for further attacks within the AWS environment, leading to a wider breach. The financial impact can range from tens of thousands to millions of dollars, depending on the scale of the breach and the sensitivity of the data compromised.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect ImportKeyPair events in CloudTrail logs (logsource: aws, service: cloudtrail).
• Review IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: ’ec2.amazonaws.com’, eventName: ‘ImportKeyPair’).
• Investigate any detected ImportKeyPair events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).
• Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.

Attack Chain

1. An attacker gains initial access to the target system, potentially through exploiting a vulnerability in a web application or service running on the server (e.g., SharePoint).
2. The attacker leverages the compromised web application to upload a malicious ASPX file to a directory within the web server’s file system, specifically targeting locations like “?:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\*”.
3. The uploaded ASPX file contains malicious code designed to provide the attacker with remote access and control over the server.
4. The attacker triggers the execution of the ASPX file by sending a request to the web server, which processes the ASPX file and executes the embedded malicious code.
5. The web shell allows the attacker to execute arbitrary commands on the server, potentially escalating privileges and moving laterally within the network.
6. The attacker uses the web shell to establish persistence on the compromised server, ensuring continued access even after the initial vulnerability is patched.
7. The attacker may use the web shell to exfiltrate sensitive data from the server or to deploy additional malware and tools.

Impact

A successful web shell deployment can lead to complete compromise of the affected server, potentially impacting numerous organizations. Attackers can use web shells to execute arbitrary code, steal sensitive data, and establish persistent access to internal networks. The impact includes data breaches, financial losses, and reputational damage. Successful exploitation of SharePoint vulnerabilities leading to web shell deployment has been observed in the wild.

Recommendation

• Deploy the Sigma rule “Web Shell ASPX File Creation in Common Directories” to detect suspicious ASPX file creation events, filtering out legitimate processes to reduce false positives.
• Enable Sysmon Event ID 11 (File Create) to capture file creation events on Windows systems, which is a data source for the Sigma rule.
• Investigate any alerts generated by the Sigma rule “Web Shell ASPX File Creation in Common Directories” by examining the file path, creating process, and network activity around the time of the event.
• Monitor web server logs for suspicious requests targeting ASPX files in common web server directories, as referenced in the rule description.

Attack Chain

1. Initial Access: An attacker gains initial access to the network through various means, such as phishing or exploiting a public-facing application.
2. Privilege Escalation: The attacker exploits a vulnerability or misconfiguration on a system within the network to achieve local administrator or SYSTEM privileges.
3. Domain Controller Compromise: The attacker uses their elevated privileges to target a domain controller, exploiting vulnerabilities or weak configurations to gain SYSTEM access on the domain controller itself.
4. Group Modification: Once the attacker has SYSTEM privileges on a domain controller, they use this access to add a user account to a privileged Active Directory group. This is done by modifying the group membership using tools native to the operating system.
5. Persistence: By adding a user account to a privileged group, the attacker ensures they have persistent access to the domain, even if their initial access method is discovered and blocked.
6. Lateral Movement: With the newly acquired group membership, the attacker can now move laterally within the network, accessing resources and systems that were previously inaccessible.
7. Data Exfiltration / Impact: The attacker leverages their access to locate and exfiltrate sensitive data, or to disrupt critical business operations.

Impact

A successful attack can lead to a wide range of negative consequences, including data breaches, system compromise, and disruption of critical business operations. Attackers can use the compromised account to access sensitive data, modify system configurations, or even deploy ransomware. The scope of impact depends on the permissions and privileges associated with the compromised account and the targeted resources. Furthermore, the incident can damage the organization’s reputation and result in regulatory fines and legal liabilities.

Recommendation

• Enable “Audit Security Group Management” to generate the necessary events for detection as detailed in the setup instructions.
• Deploy the following Sigma rule to detect potential Active Directory group modifications by the SYSTEM account and tune for your environment.
• Investigate any event with event code 4728 where the SubjectUserSid is “S-1-5-18” as described in the overview.
• Review the investigation guide outlined in the rule description for triage and analysis steps.

Attack Chain

1. Initial Compromise: An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.
2. Privilege Escalation: The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.
3. SSH Certificate Authority Creation: The attacker creates a new SSH certificate authority within the GitHub organization (ssh_certificate_authority.create).
4. Disable SSH Certificate Requirement: Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (ssh_certificate_requirement.disable). This action allows attackers to bypass security controls that enforce SSH certificate usage.
5. Unauthorized Access: The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.
6. Lateral Movement: The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.
7. Data Exfiltration/Malicious Code Injection: The attacker exfiltrates sensitive data or injects malicious code into the organization’s repositories.
8. Persistence: The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.

Impact

Successful modification of SSH certificate configurations in GitHub can lead to unauthorized code commits, data breaches, and supply chain attacks. This could result in financial losses, reputational damage, and legal repercussions for the affected organization. The number of affected repositories and the severity of the impact depend on the scope of the attacker’s access and the sensitivity of the compromised data.

Recommendation

• Enable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).
• Deploy the provided Sigma rule to detect ssh_certificate_authority.create or ssh_certificate_requirement.disable events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).
• Regularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.

Attack Chain

1. An attacker gains initial access to a Linux system via some vulnerability or compromised credentials.
2. The attacker identifies binaries with SUID/SGID bits set.
3. The attacker executes a vulnerable SUID/SGID binary, such as find or nmap.
4. The binary executes with root privileges, even though the attacker is a non-root user.
5. The attacker leverages the elevated privileges to read sensitive files, modify system configurations, or install malicious software.
6. The attacker escalates privileges to root.
7. The attacker establishes persistence by creating a new SUID/SGID binary or modifying an existing one.

Impact

Successful exploitation of SUID/SGID misconfigurations can lead to complete system compromise, as attackers gain root privileges. Attackers can install malware, steal sensitive data, or disrupt critical services. The impact can range from data breaches to denial-of-service attacks. Given the broad range of binaries potentially affected, this vulnerability can impact various sectors and potentially affect a large number of Linux systems.

Recommendation

• Deploy the provided Sigma rule Privilege Escalation via SUID/SGID to your SIEM to detect potential privilege escalation attempts.
• Enable Elastic Defend integration to ensure the necessary process execution data is available.
• Regularly audit SUID/SGID permissions across your Linux systems and remove unnecessary SUID/SGID bits.
• Investigate any alerts generated by the Sigma rule by checking process.real_user.id and process.real_group.id to determine if non-root users initiated the process.
• Review the process details, including process.name and process.args, to understand the nature of the executed command and its intended function.
• Monitor system logs for suspicious activity around the time of the alert to identify any related actions.

Attack Chain

1. Initial Access: The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.
2. Discovery: The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.
3. Configuration Modification: The attacker uses kubectl or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.
4. Webhook Deployment: The malicious webhook is deployed as a service within the Kubernetes cluster.
5. API Interception: When a user or application makes an API request that matches the webhook’s defined rules, the webhook intercepts the request.
6. Malicious Code Injection: The webhook injects malicious code or alters the API request to achieve the attacker’s objectives (e.g., granting unauthorized permissions, modifying resource configurations).
7. Persistence/Privilege Escalation/Credential Access: Depending on the injected code, the attacker achieves persistence by ensuring malicious code is always present, escalates privileges by modifying role bindings, or accesses credentials by intercepting secret creation requests.
8. Lateral Movement/Data Exfiltration: The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.

Impact

Successful modification of Kubernetes admission controllers can have severe consequences. This can result in unauthorized access to sensitive data, complete cluster compromise, and denial of service. The impact ranges from data breaches and service disruptions to long-term persistence within the environment, allowing attackers to maintain control over the cluster. The stealthy nature of this attack makes it difficult to detect, potentially allowing attackers to operate undetected for extended periods.

Recommendation

• Deploy the Sigma rule “Kubernetes Admission Controller Modification” to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).
• Monitor Kubernetes audit logs for create, delete, patch, replace, and update verbs on mutatingwebhookconfigurations and validatingwebhookconfigurations resources (logsource: kubernetes, service: audit).
• Implement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.
• Regularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.

Attack Chain

1. An attacker gains initial access to a compromised system, potentially through phishing, exploitation of a vulnerability, or stolen credentials.
2. The attacker leverages msiexec.exe to create a new scheduled task using the schtasks.exe command, setting it to execute a malicious script or binary.
3. Alternatively, the attacker uses msiexec.exe in conjunction with reg.exe or PowerShell to modify registry keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run or HKCU\Software\Microsoft\Windows\CurrentVersion\Run, adding a pointer to their malicious executable.
4. The created scheduled task or registry entry points to a malicious payload, such as a reverse shell or a downloader.
5. The system is restarted, or the user logs on, triggering the execution of the newly created scheduled task or the malicious binary through the modified registry run key.
6. The malicious payload executes, establishing a persistent foothold for the attacker on the compromised system.
7. The attacker can now perform further actions, such as data exfiltration, lateral movement, or deployment of ransomware.

Impact

Successful exploitation allows the adversary to maintain persistent access to the compromised system. This can lead to data theft, system compromise, deployment of ransomware, or use of the system as a staging point for further attacks within the network. A single compromised system can be used to pivot and compromise additional systems, leading to a widespread security breach. The impact can include financial losses, reputational damage, and disruption of business operations.

Recommendation

• Monitor process creation events for msiexec.exe spawning schtasks.exe or reg.exe to create scheduled tasks or modify registry run keys (reference: rules in this brief).
• Implement and tune the Sigma rules provided in this brief to detect suspicious msiexec.exe activity related to persistence mechanisms.
• Review and audit existing scheduled tasks and registry run keys for any suspicious entries or anomalies.
• Enable file integrity monitoring (FIM) on critical system directories, including the Windows Task Scheduler directory and registry run key locations (reference: event.category == “file” and file.path … and event.category == “registry” and registry.path … in the rule query).
• Implement application control policies to restrict the execution of unauthorized or unknown executables (reference: rule query).

Attack Chain

1. An attacker gains initial access to the system through unspecified means.
2. The attacker modifies the DNS Server configuration to enable the loading of server-level plugin DLLs.
3. The attacker places a malicious, unsigned DLL in a location accessible to the DNS service.
4. The DNS service (dns.exe) loads the malicious DLL upon startup or configuration change.
5. The malicious DLL executes code within the context of the DNS service, inheriting SYSTEM privileges.
6. The attacker uses the elevated privileges to perform malicious actions, such as installing backdoors or modifying system settings.
7. The attacker maintains persistence by ensuring the malicious DLL is loaded on subsequent system restarts.

Impact

Successful exploitation allows attackers to execute arbitrary code with SYSTEM privileges, granting them complete control over the compromised system. This can lead to data theft, system corruption, or the installation of persistent backdoors. The impact includes potential privilege escalation, remote code execution, and complete system compromise.

Recommendation

• Deploy the Sigma rule “Unsigned DLL loaded by DNS Service” to your SIEM and tune for your environment.
• Ensure Sysmon Event ID 7 (Image Loaded) is enabled to provide the necessary data for the detection rule.
• Investigate any alerts generated by the Sigma rule by reviewing the DLL file path and code signature status.
• Regularly review and validate the DNS server configuration to ensure that only trusted DLLs are loaded.
• Implement code signing policies to prevent the loading of unsigned DLLs.

Attack Chain

1. The attacker gains unauthorized access to a system with ScreenConnect installed. This could be achieved through exploiting vulnerabilities like CVE-2024-1709 and CVE-2024-1708, or through credential compromise.
2. The attacker uses ScreenConnect to connect to the compromised system remotely.
3. The attacker uses the ScreenConnect interface to execute commands on the remote system.
4. The attacker spawns a command interpreter, such as cmd.exe, using ScreenConnect. This process is a child process of the ScreenConnect client process.
5. The attacker uses cmd.exe to execute malicious commands, such as downloading and executing a malicious payload.
6. Alternatively, the attacker spawns powershell.exe with encoded commands or commands to download and execute malicious payloads from a remote server.
7. The attacker establishes persistence by creating a scheduled task using schtasks.exe or creates a new service using sc.exe.
8. The attacker uses tools like net.exe to modify user accounts or privileges to maintain access to the compromised system.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, installation of malware, and establishment of persistent access to the compromised system. This can result in data theft, disruption of services, and further lateral movement within the network. The number of victims and specific sectors targeted varies depending on the attacker’s objectives, but the impact can be significant for organizations relying on ScreenConnect for remote support.

Recommendation

• Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious child processes spawned by ScreenConnect and tune for your environment.
• Monitor process creation events for ScreenConnect client processes spawning suspicious child processes like powershell.exe, cmd.exe, net.exe, schtasks.exe, sc.exe, rundll32.exe, mshta.exe, certutil.exe, wscript.exe, cscript.exe, curl.exe, ssh.exe, scp.exe, wevtutil.exe, wget.exe, or wmic.exe as detailed in the Sigma rules.
• Enable Sysmon process-creation logging to capture the necessary process execution data to activate the rules above.
• Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe as described in the attack chain.

Attack Chain

1. An attacker gains initial access to an Okta account, possibly through credential phishing or brute-force attacks.
2. The attacker attempts to log in to the Okta Admin Console.
3. Okta’s behavior detection engine analyzes the login attempt, considering factors like the user’s location, device, and time of day.
4. The system logs record a policy.evaluate_sign_on event when a sign-on policy is evaluated.
5. The target.displayName field within the log specifies “Okta Admin Console” indicating the user is attempting to access the administrative interface.
6. If Okta identifies the behavior as unusual, the debugContext.debugData.behaviors or debugContext.debugData.logOnlySecurityData fields will contain “POSITIVE”.
7. An alert is triggered based on the identified unusual behavior.
8. The attacker, if successful in bypassing initial checks, may proceed to create new admin accounts, modify existing policies, or exfiltrate sensitive data.

Impact

Compromise of the Okta Admin Console can lead to significant damage, including unauthorized access to sensitive data, modification of security policies, creation of rogue administrator accounts, and ultimately, a complete takeover of the Okta environment. This can impact all applications and services integrated with Okta, potentially affecting thousands of users and causing significant financial and reputational damage. Early detection is crucial to limiting the scope and impact of such attacks.

Recommendation

• Deploy the provided Sigma rule Okta Admin Console Unusual Behavior to your SIEM to detect suspicious Okta Admin Console access based on Okta’s internal behavior analysis.
• Investigate any alerts generated by the Sigma rule to determine if the unusual behavior is legitimate or indicative of malicious activity.
• Review Okta’s System Log API documentation to understand the various event types and data fields available for monitoring and detection.
• Implement multi-factor authentication (MFA) for all Okta accounts, especially administrator accounts, to mitigate the risk of account compromise (related to initial access).
• Monitor Okta’s security advisories and announcements for updates on emerging threats and recommended security practices (references).

Attack Chain

1. An attacker gains initial access to an Azure AD account with sufficient privileges to modify authentication policies (e.g., Global Administrator).
2. The attacker modifies the Azure AD authentication methods policy to enable certificate-based authentication.
3. The attacker registers a certificate authority (CA) in Azure AD, which will be used to issue certificates for authentication.
4. The attacker crafts or compromises a certificate that is trusted by the registered CA.
5. The attacker uses the crafted certificate to authenticate to Azure AD, bypassing traditional password-based authentication.
6. The attacker leverages the newly gained access to provision new resources, modify existing configurations, or access sensitive data.
7. The attacker establishes persistence by creating service principals or applications that authenticate using certificates, allowing them to maintain access even if the initial account is compromised.

Impact

Successful exploitation of CBA can lead to full compromise of an Azure AD tenant. Attackers can gain access to sensitive data, disrupt services, and deploy malicious applications. The lack of multi-factor authentication on certificate-based logins significantly increases the risk of unauthorized access. The impact can range from data breaches and financial losses to complete operational shutdown, depending on the scope of the compromised resources.

Recommendation

• Deploy the Sigma rule to detect when certificate-based authentication is enabled in Azure AD (Authentication Methods Policy Update in Audit Logs).
• Monitor Azure AD audit logs for modifications to authentication methods policies, paying close attention to changes related to certificate-based authentication.
• Implement strong certificate management practices, including proper key storage, certificate revocation, and monitoring of certificate usage.
• Investigate any unexpected changes to Azure AD authentication policies or the registration of new certificate authorities.

Attack Chain

1. User launches a communication application (e.g., Slack, Teams, Webex).
2. The communication application executes a vulnerable or compromised component.
3. The compromised component spawns a child process (e.g., powershell.exe, cmd.exe).
4. The child process executes a malicious command or script.
5. The script attempts to download additional payloads from an external source.
6. The payload executes, establishing persistence through registry modification or scheduled tasks.
7. The attacker gains remote access to the system.
8. Data exfiltration or lateral movement within the network occurs.

Impact

A successful attack can lead to the compromise of sensitive data, installation of malware, and potential lateral movement within the organization’s network. By exploiting communication applications, attackers can gain access to internal communications, confidential documents, and user credentials. The number of affected users and the extent of the damage depend on the compromised application and the attacker’s objectives. If successful, this attack may lead to significant financial loss, reputational damage, and disruption of business operations.

Recommendation

• Deploy the Sigma rule Suspicious Communication App Child Process to your SIEM to detect anomalous child processes spawned by communication applications and tune for your environment.
• Enable process creation logging with command line arguments in Windows to ensure that the Sigma rule has the necessary data to function correctly (logsource: process_creation, product: windows).
• Investigate any alerts generated by the rule and review the command line arguments of the spawned processes to identify potential malicious activity.
• Implement application whitelisting to restrict the execution of unauthorized applications and reduce the attack surface.
• Ensure that all communication applications are updated to the latest versions to patch known vulnerabilities and reduce the risk of exploitation.
• Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server, referencing the setup guide.

Attack Chain

1. Initial access is achieved through an existing compromised account or vulnerability.
2. The attacker uses takeown.exe /f <file> to take ownership of a target file or directory.
3. The attacker uses icacls.exe <file> /reset to reset the ACL of the file or directory.
4. Alternatively, the attacker uses icacls.exe <file> /grant Everyone:F to grant full control to everyone, weakening security.
5. The attacker modifies the contents of the file, such as injecting malicious code or configuration changes.
6. The attacker leverages the modified file for persistence, such as a modified system DLL loaded at boot.
7. The system executes the malicious code when the compromised file is accessed or executed.
8. The attacker achieves their objective, such as maintaining persistence, escalating privileges, or executing arbitrary commands.

Impact

Compromising file and directory permissions can lead to significant security breaches. Successful attacks can allow unauthorized access to sensitive data, system instability, or the execution of malicious code with elevated privileges. This can affect any Windows environment where file permissions are improperly managed, with potential for widespread system compromise and data exfiltration. The impact is most severe on systems containing sensitive data or critical infrastructure components.

Recommendation

• Monitor process execution for icacls.exe and takeown.exe with suspicious arguments targeting system files (e.g., C:\Windows\*) to detect potential permission modification attempts using the provided Sigma rules.
• Enable Windows Security Auditing for file system changes to capture events related to permission modifications and ownership changes.
• Deploy the provided Sigma rules to your SIEM and tune for your environment, specifically focusing on processes modifying permissions on files within the C:\Windows\ directory.
• Investigate any alerts triggered by the Sigma rules, focusing on the process execution chain and the target files being modified.

Attack Chain

1. Attacker gains initial access to the target system through unspecified means.
2. Attacker creates a malicious DLL to be used as a Netsh Helper DLL.
3. Attacker modifies the Windows Registry to add the malicious DLL as a Netsh Helper DLL under HKLM\Software\Microsoft\netsh\.
4. The system administrator or a scheduled task executes netsh.exe.
5. netsh.exe loads and executes the malicious DLL, granting the attacker code execution.
6. The malicious DLL performs its intended actions, such as establishing a reverse shell or deploying additional malware.
7. The attacker maintains persistence on the system through the malicious Netsh Helper DLL.

Impact

Successful exploitation allows attackers to establish persistent access to a compromised system. This can lead to data theft, system compromise, and further malicious activities. While the risk score is low, the persistence mechanism can allow attackers to maintain a foothold for extended periods, increasing the potential for significant damage.

Recommendation

• Monitor registry modifications under the HKLM\Software\Microsoft\netsh\ path for suspicious DLL additions using the “Netsh Helper DLL Registry Modification” Sigma rule.
• Enable Sysmon registry event logging to collect the necessary data for the Sigma rule.
• Investigate any alerts generated by the Sigma rule by reviewing the DLL file properties, timestamps, and related processes.

Attack Chain

1. An attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).
2. The attacker authenticates to the GitHub organization or repository.
3. The attacker navigates to the settings for the organization, environment, codespaces, or repository.
4. The attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.
5. The secret is stored within GitHub’s infrastructure, accessible to GitHub Actions workflows.
6. The attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.
7. The workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.
8. The attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, code injection, and supply chain compromise. The impact ranges from low, in cases where the secret is used for benign purposes, to critical if the secret is used to deploy malicious code into production environments. While the number of affected organizations is unknown, the potential for widespread impact across the software supply chain makes this a critical area for monitoring.

Recommendation

• Enable GitHub audit log streaming to capture the events necessary for this detection (see logsource definition).
• Deploy the Sigma rule Github New Secret Created to your SIEM and tune for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on the “actor” involved in creating the secret.

Attack Chain

1. An attacker gains initial access to the system, potentially through social engineering or exploiting a software vulnerability.
2. The attacker executes a script (VBScript, JScript) via wscript.exe or cscript.exe.
3. The script contains commands to modify specific registry keys, such as the Run key for persistence (T1547.001).
4. The scripting engine process (e.g., wscript.exe) directly interacts with the Windows Registry to set the new values.
5. Upon system restart or user logon, the modified registry key triggers the execution of a malicious payload.
6. The attacker achieves persistence on the compromised system, allowing for continued access and control.
7. The attacker leverages the persistent access to perform lateral movement or data exfiltration.

Impact

Successful exploitation can lead to persistent access on compromised systems, enabling attackers to execute malicious code, steal sensitive information, or disrupt critical services. The registry modifications performed by scripting engines can bypass traditional security measures and make it difficult to detect and remediate the attack. This can result in significant data loss, financial damage, and reputational harm to affected organizations.

Recommendation

• Deploy the Sigma rule “Registry Tampering by Potentially Suspicious Processes” to your SIEM to detect suspicious registry modifications made by scripting engines.
• Investigate any alerts generated by the Sigma rule “Registry Tampering by Potentially Suspicious Processes” for unusual or unauthorized registry changes.
• Monitor registry events for modifications made by processes such as wscript.exe and cscript.exe (logsource: registry_event).

Attack Chain

1. An attacker gains initial access to a system, often through phishing or exploiting a vulnerability.
2. The attacker establishes a foothold and escalates privileges to make necessary registry modifications.
3. The attacker modifies the HKCU\Software\Microsoft\Office Test\Special\Perf registry key, adding a new entry or modifying an existing one to point to a malicious DLL.
4. The attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.
5. A user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).
6. The Office application loads the DLL specified in the “Office Test” registry key during startup.
7. The malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.
8. The attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.

Impact

Successful exploitation allows attackers to maintain persistent access to a compromised system. The injected DLL can be used to execute arbitrary code, potentially leading to data theft, malware installation, or further compromise of the network. The relatively low risk score suggests a common technique, but the potential for persistent access makes it a significant threat.

Recommendation

• Deploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the “Office Test” registry key (HKCU\Software\Microsoft\Office Test\Special\Perf\*).
• Enable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.
• Monitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.
• Implement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.

Attack Chain

1. Attacker gains initial access to the system with administrator privileges.
2. Attacker identifies a legitimate service or creates a new service to abuse for privilege escalation.
3. Attacker modifies the service configuration to execute a command shell (cmd.exe, powershell.exe, pwsh.exe, or powershell_ise.exe). This may involve modifying the service’s executable path or adding command-line arguments.
4. The system’s Service Control Manager (SCM) starts the service.
5. services.exe spawns the configured command shell process.
6. The command shell executes with SYSTEM privileges.
7. Attacker uses the SYSTEM shell to perform malicious activities, such as installing malware, accessing sensitive data, or creating new user accounts.
8. The service continues to run, providing persistent access to the system.

Impact

Successful exploitation leads to privilege escalation to SYSTEM, granting the attacker complete control over the compromised system. This can result in data theft, malware installation, or further lateral movement within the network. The rule has a risk score of 47 and is categorized as medium severity.

Recommendation

• Deploy the Sigma rule System Shells via Services to detect the execution of command shells spawned by services.exe within your SIEM environment, and tune for your environment.
• Investigate any process creation events where services.exe is the parent process of cmd.exe, powershell.exe, pwsh.exe, or powershell_ise.exe using the investigation guide provided in the content section.
• Review service creation and modification events in Windows Event Logs (Event IDs 4697 and 7045) for suspicious entries.
• Enable Sysmon process creation logging (Event ID 1) to capture detailed process information.
• Utilize osquery to retrieve detailed service information to identify potentially malicious services. Reference queries $osquery_0, $osquery_1, and $osquery_2 in the investigation guide.

Attack Chain

1. The user’s system is compromised, potentially through social engineering or existing malware.
2. The attacker gains access to the system and attempts to install a malicious browser extension.
3. The attacker drops the extension file (.xpi for Firefox, .crx for Chromium) into the appropriate browser extension directory (e.g., C:\\Users\\*\\AppData\\Roaming\\*\\Profiles\\*\\Extensions\\ for Firefox or C:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\Webstore Downloads\\ for Chromium).
4. A file creation event is triggered as the extension file is created in the target directory.
5. The detection rule identifies this file creation event based on the file name and path, filtering out known safe processes like firefox.exe.
6. The malicious extension installs itself into the browser.
7. The extension gains persistence by loading every time the browser starts.
8. The attacker can now perform malicious actions such as monitoring browsing activity, stealing credentials, or injecting malicious content into web pages.

Impact

A successful attack using malicious browser extensions can lead to persistent access to the compromised system, allowing attackers to steal sensitive information such as credentials, financial data, or personal information. This can result in financial loss, identity theft, and reputational damage. The installation of malicious extensions can also lead to the injection of malicious content into web pages, redirecting users to phishing sites or distributing malware. The scope of the impact can range from individual users to entire organizations, depending on the extent of the compromise.

Recommendation

• Enable Sysmon Event ID 11 (File Create) logging to capture the necessary file creation events for this detection.
• Deploy the provided Sigma rule Browser Extension Install via File Creation to your SIEM and tune the exclusions for your specific environment.
• Review and update the list of known safe processes and extensions in the Sigma rule Browser Extension Install via File Creation to minimize false positives.
• Implement application whitelisting policies to restrict the installation of unauthorized browser extensions.
• Educate users on the risks associated with installing browser extensions from untrusted sources and encourage them to only install extensions from official browser stores.
• Implement policies to regularly review installed browser extensions across the organization.

Attack Chain

1. An attacker gains initial access to a system through other means (e.g., phishing, exploitation of a vulnerability).
2. The attacker uses the BITSAdmin tool or PowerShell cmdlets to create a new BITS job.
3. The attacker configures the BITS job to download a malicious payload or execute a malicious script.
4. The attacker utilizes the SetNotifyCmdLine method to set a command that will be executed upon job completion or a specified state change.
5. The BITS service executes the specified command, which can be a script interpreter (e.g., powershell.exe, cmd.exe) or a malicious executable.
6. The malicious command downloads or executes further payloads, establishing persistence on the system.
7. The attacker maintains persistent access, allowing them to execute commands, steal data, or perform other malicious activities.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems. This can lead to data theft, further malware deployment, or complete system compromise. The BITS service runs with elevated privileges, so any command executed via SetNotifyCmdLine will also run with those privileges. This persistence mechanism is difficult to detect because BITS is a legitimate Windows service, and its activity can be easily masked as normal system operations.

Recommendation

• Monitor process creation events for processes spawned by svchost.exe with arguments containing “BITS” but not in the exclusion list (WerFaultSecure.exe, WerFault.exe, wermgr.exe, directxdatabaseupdater.exe) using the “Persistence via BITS Job Notify Cmdline” rule.
• Implement the Sigma rule “Detect Suspicious BITS Job Creation” to identify unusual BITS job creation activities.
• Review BITS job configurations on systems to identify and remove any unauthorized or suspicious jobs.
• Enable Sysmon process creation logging to capture detailed information about process execution, including parent-child relationships and command-line arguments.

Attack Chain

1. Initial Access: An attacker gains initial access using compromised credentials or brute-force techniques targeting Google Workspace accounts.
2. Login Attempt: The attacker attempts to log in to a Google Workspace account using a less secure application (e.g., an older email client without modern authentication) or via programmatic login.
3. Suspicious Activity Detection: Google’s internal systems analyze the login attempt and flag it as suspicious based on various risk factors, such as unusual location, time of day, or login method.
4. Event Logging: Google Workspace logs the suspicious login event, including the reason for the classification (e.g., ‘suspicious_login_less_secure_app’).
5. Potential Privilege Escalation: Upon successful login, the attacker may attempt to escalate privileges within the Google Workspace environment to gain broader access.
6. Defense Evasion: The attacker might use techniques to evade detection, such as disabling security features or modifying audit logs.
7. Persistence: The attacker establishes persistence by creating new accounts, modifying existing ones, or installing malicious apps.
8. Data Exfiltration/Malicious Activity: The attacker uses the compromised account to exfiltrate sensitive data or perform other malicious activities, such as sending phishing emails.

Impact

Successful exploitation can lead to unauthorized access to sensitive data stored within Google Workspace, including emails, documents, and other files. This can result in data breaches, financial loss, and reputational damage. The number of affected users depends on the scope of the compromised account and the attacker’s ability to escalate privileges. Targeted sectors are broad, affecting any organization relying on Google Workspace for collaboration and data storage.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious login activity classified by Google Workspace (logsource: gcp, service: google_workspace.login).
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the login attempt and take appropriate action, such as resetting passwords or disabling compromised accounts.
• Enforce multi-factor authentication (MFA) for all Google Workspace accounts to mitigate the risk of credential compromise.
• Disable or restrict the use of less secure apps within Google Workspace to reduce the attack surface.
• Monitor Google Workspace audit logs for other suspicious activities, such as unusual file access or data exfiltration attempts.

Attack Chain

1. An attacker gains initial access to an Okta tenant with sufficient administrative privileges, either through compromised credentials or by exploiting a vulnerability.
2. The attacker navigates to the Okta admin console.
3. The attacker creates a new identity provider (IdP) within the Okta tenant (system.idp.lifecycle.create).
4. The attacker configures the rogue IdP with attacker-controlled settings, such as SAML endpoints or OIDC configurations, potentially pointing to an attacker-controlled server.
5. The attacker configures routing rules within Okta to direct specific users or groups to authenticate through the newly created, malicious IdP.
6. Users attempting to access Okta-protected applications are redirected to the attacker-controlled IdP for authentication.
7. The attacker’s IdP captures user credentials or issues fraudulent authentication tokens, allowing the attacker to impersonate legitimate users.
8. The attacker leverages the stolen credentials or fraudulent tokens to access sensitive applications and data protected by Okta, achieving their objective of data theft or service disruption.

Impact

A successful attack involving the creation of a rogue Okta identity provider can lead to significant consequences. Attackers can gain persistent access to the Okta environment, bypass multi-factor authentication, and impersonate legitimate users. This can result in unauthorized access to sensitive applications and data, data breaches, financial loss, and reputational damage. The scope of the impact depends on the privileges of the compromised accounts and the sensitivity of the data accessed.

Recommendation

• Deploy the Sigma rule “Okta Identity Provider Created” to your SIEM to detect the creation of new identity providers and tune it for your environment.
• Regularly review and validate all configured identity providers within your Okta tenant to ensure their legitimacy.
• Implement strong access controls and multi-factor authentication for all Okta administrative accounts to prevent unauthorized creation of identity providers.
• Monitor Okta system logs for suspicious activity related to identity provider configuration and authentication.
• Investigate any alerts triggered by the “Okta Identity Provider Created” Sigma rule to determine the legitimacy of the IdP creation event.

Attack Chain

1. A user (non-root) executes a binary that has the SUID or SGID bit set.
2. The system checks the permissions of the executable and identifies the SUID/SGID bit.
3. The process spawns with the effective UID/GID set to the owner/group of the executable file (typically root).
4. The process attempts to perform actions that require elevated privileges.
5. If the SUID/SGID binary is vulnerable, the attacker can leverage it to execute arbitrary commands as root.
6. The attacker escalates privileges to root, gaining full control over the system.
7. The attacker installs a backdoor for persistent access.
8. The attacker performs malicious activities, such as data exfiltration or system compromise.

Impact

Successful exploitation of SUID/SGID misconfigurations can grant an attacker root-level access to a Linux system. This can lead to complete system compromise, including data theft, installation of malware, and the potential for lateral movement to other systems on the network. A single compromised system can be leveraged to attack other internal assets.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect potential SUID/SGID exploitation (see the rules section).
• Review the SUID/SGID binaries identified by the rule and verify their configurations to ensure they are correctly set and necessary.
• Implement enhanced monitoring and logging for SUID/SGID execution attempts to detect and respond to similar threats in the future (Data Source: Elastic Defend).
• Consider implementing stricter access controls and reducing the number of SUID/SGID binaries on the system to minimize the attack surface.
• Investigate the parent process of the flagged binaries to determine the origin of the execution and whether it aligns with expected behavior.

Attack Chain

1. Initial Access: The attacker gains initial access to a target system through various methods, such as exploiting vulnerabilities or using compromised credentials.
2. Tool Deployment: The attacker deploys a remote monitoring and management (RMM) tool or remote access software on the compromised endpoint. This may involve downloading and installing the tool, or exploiting existing installations.
3. Persistence: The RMM tool is configured to run persistently on the system, ensuring that the attacker maintains access even after a reboot or other disruption. This may involve creating a service or adding a registry key to ensure the tool starts automatically.
4. Command and Control: The attacker uses the RMM tool to establish a command and control (C2) channel with the compromised system. This allows them to remotely execute commands, transfer files, and monitor activity on the system.
5. Lateral Movement: Using the RMM tool, the attacker moves laterally within the network, compromising additional systems and escalating their access. This may involve using the tool to access shared resources or execute commands on other systems.
6. Data Exfiltration or Ransomware Deployment: The attacker uses their access to exfiltrate sensitive data from the compromised network or deploy ransomware to encrypt files and demand a ransom payment.
7. Cleanup: The attacker may attempt to remove traces of their activity, such as logs or files associated with the RMM tool, to avoid detection.

Impact

Compromise via RMM tools can lead to significant data breaches, financial losses, and reputational damage. The use of legitimate tools makes detection more difficult. Successful attacks can result in ransomware deployment, data theft, and prolonged unauthorized access to sensitive systems. Organizations in all sectors are potentially at risk.

Recommendation

• Deploy the process creation rule to detect the execution of RMM tools on endpoints based on process.name and process.code_signature.subject_name criteria in the query.
• Enable Sysmon process creation logging (Event ID 1) to ensure the collection of necessary event data for the detection rule.
• Investigate any alerts generated by the detection rule to determine whether the execution of the RMM tool is authorized and legitimate. Refer to the references for a list of commonly abused RMM tools and associated indicators.

Attack Chain

1. Initial Access: Attacker gains unauthorized access to an Okta account, possibly through credential phishing, brute-force attacks, or exploitation of vulnerabilities.
2. Privilege Check: The attacker verifies the privileges of the compromised account to determine if it has sufficient permissions to create new admin role assignments.
3. Account Impersonation: The attacker uses the compromised account to access the Okta admin dashboard.
4. Role Assignment Creation: The attacker navigates to the role assignment section and initiates the creation of a new admin role assignment.
5. Configuration: The attacker specifies the target user or group for the new admin role assignment.
6. Audit Logging: Okta logs the event ‘iam.resourceset.bindings.add’ indicating the creation of a new admin role assignment.
7. Persistence: The attacker uses the newly created admin role assignment to maintain persistent access to the Okta environment even if the initial compromised account is detected and remediated.

Impact

Successful exploitation could lead to complete control over the Okta environment, affecting all connected applications and services. An attacker with admin privileges can modify user accounts, reset passwords, access sensitive data, and potentially compromise the entire organization. The number of affected users and systems depends on the scope of the Okta deployment, but the impact can be significant, potentially affecting thousands of users and critical business operations.

Recommendation

• Deploy the Sigma rule Okta Admin Role Assignment Created to your SIEM and tune it for your environment to detect suspicious admin role creation activity in Okta logs.
• Investigate any alerts generated by the Okta Admin Role Assignment Created rule to determine if the role assignment was legitimate and authorized.
• Implement multi-factor authentication (MFA) for all Okta accounts, especially those with administrative privileges, to mitigate the risk of credential compromise.
• Regularly review and audit Okta admin role assignments to identify and remove any unnecessary or unauthorized privileges.

Attack Chain

1. Initial access to the Azure environment is gained, potentially through credential phishing or other means.
2. The attacker identifies a target user account with sufficient privileges.
3. The attacker accesses the Azure Active Directory (Azure AD) settings for the compromised user.
4. The attacker navigates to the “Security info” section of the user’s profile.
5. The attacker registers a new authentication method, such as a phone number or email address, controlled by the attacker. This action generates an audit log event with OperationName “User registered security info”.
6. The attacker can now use the newly added authentication method to bypass multi-factor authentication.
7. The attacker leverages the compromised account to access sensitive data, applications, or resources within the Azure environment.
8. The attacker maintains persistent access to the Azure environment, even if the original account password is changed.

Impact

Successful addition of rogue authentication methods allows attackers to maintain persistent access to compromised accounts within Azure environments. This can lead to data breaches, unauthorized access to sensitive applications, privilege escalation, and lateral movement within the cloud infrastructure. The impact can range from data exfiltration to complete control over the targeted Azure resources.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect changes to authentication methods within Azure audit logs (logsource: azure, service: auditlogs).
• Investigate any instances where the OperationName is User registered security info in the Azure Audit Logs, as this indicates a change in authentication method.
• Review the referenced Microsoft documentation on privileged account security to understand best practices for securing administrative accounts (references).

Attack Chain

1. Initial Access: The attacker gains initial access to the system through various means.
2. Privilege Escalation: The attacker attempts to escalate privileges to SYSTEM.
3. Service Creation: The attacker creates a new Windows service using tools like sc.exe or modifies an existing one.
4. Image Path Modification: The attacker sets the service’s ImagePath to point to a command interpreter (e.g., cmd.exe, powershell.exe) or a script file.
5. Command Execution: The service executes the command interpreter or script with SYSTEM privileges.
6. Persistence: The attacker configures the service to start automatically on system boot, ensuring persistent access.
7. Malicious Activity: The attacker uses the elevated privileges to perform malicious activities, such as installing malware, stealing credentials, or compromising other systems.

Impact

Successful exploitation allows attackers to maintain persistent access to the compromised system with SYSTEM privileges. This can lead to complete system compromise, data theft, installation of ransomware, and lateral movement to other systems within the network. The impact includes potential data breaches, financial losses, and reputational damage.

Recommendation

• Enable Windows Security Event Logs and Windows System Event Logs to capture service creation events (Event IDs 4697 and 7045).
• Deploy the Sigma rule Suspicious Service Installation via ImagePath to your SIEM to detect suspicious service creations.
• Investigate any alerts generated by the Sigma rule by examining the service’s ImagePath and associated processes.
• Use the Osquery queries provided in the source to investigate existing services, unsigned executables, and drivers for suspicious characteristics.
• Monitor for registry changes related to service creation or modification.

Attack Chain

1. An adversary gains initial access to the system through an undisclosed method (e.g., exploitation of a vulnerability or social engineering).
2. The attacker creates a malicious, unsigned DLL on the compromised system in a non-standard directory like C:\ProgramData\.
3. The attacker modifies the Windows Registry to configure a service hosted by svchost.exe to load the malicious DLL. This often involves manipulating service dependencies or service parameters.
4. The system is restarted, or the targeted service is manually restarted, causing svchost.exe to load the specified DLL.
5. svchost.exe executes the code within the malicious DLL, now running with the privileges of the hosted service (typically SYSTEM).
6. The malicious DLL performs actions such as installing backdoors, escalating privileges further, or establishing command and control (C2) communication.
7. The attacker uses the established C2 channel to remotely control the compromised system, exfiltrate data, or perform other malicious activities.
8. The attacker maintains persistence on the system by ensuring the malicious DLL is loaded each time the service or system starts.

Impact

Successful exploitation allows attackers to gain persistent access to the compromised system with elevated (SYSTEM) privileges. This can lead to complete system compromise, data theft, installation of backdoors, and lateral movement within the network. The use of svchost.exe as a host for malicious DLLs makes detection more difficult, allowing attackers to operate undetected for extended periods.

Recommendation

• Implement the provided Sigma rule to detect unsigned DLLs loaded by svchost.exe, focusing on the specified file paths and code signature status.
• Examine dll.Ext.relative_file_creation_time to identify DLLs created shortly before being loaded to catch newly created malicious files.
• Review and validate the legitimacy of all DLLs loaded by svchost.exe, focusing on those located in unusual paths.
• Update endpoint detection and response (EDR) systems to specifically monitor for the loading of unsigned DLLs by system processes like svchost.exe.
• Continuously update the exclusion list of known good DLL hashes to reduce false positives.

Attack Chain

1. Initial access is gained via exploitation of a vulnerability in a web application or web server component running on a Linux system (e.g., through SQL injection or remote code execution).
2. A web shell is uploaded to the compromised web server, often disguised as a legitimate file or hidden within existing directories.
3. The attacker interacts with the web shell through HTTP requests, using it as a command and control interface.
4. The web shell executes commands on the server, initiating outbound network connections to non-standard ports.
5. These connections may be used to communicate with external C2 servers, download additional payloads, or exfiltrate sensitive data.
6. The attacker uses the web shell to move laterally within the network, targeting other systems and services.
7. The attacker attempts to establish persistence on the compromised server, ensuring continued access even after system reboots.
8. The final objective is data theft, system compromise, or disruption of services.

Impact

Compromised web servers can lead to significant data breaches, system downtime, and reputational damage. While this rule triggers on low-severity behavior, successful exploitation can lead to complete system compromise. The number of affected systems depends on the scope of the initial vulnerability and the attacker’s ability to move laterally. Organizations in all sectors that rely on web-based applications are potentially at risk.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect web server processes initiating connections to unusual destination ports and tune for your environment.
• Enable Elastic Defend integration to collect the necessary network event data from Linux endpoints to activate the rule.
• Review and customize the list of excluded destination ports and internal IP ranges in the Sigma rule to match your organization’s specific network configuration and legitimate traffic patterns.
• Investigate any alerts generated by the rule to determine if the activity is malicious or benign, focusing on the process name, user, destination IP, and destination port.

Attack Chain

1. Initial Access: The attacker gains initial access to an account with sufficient privileges to view and modify Azure Active Directory settings. This could be through phishing, password spraying, or exploiting a vulnerability.
2. Privilege Escalation: The attacker escalates privileges within Azure AD to gain the necessary permissions to manage Conditional Access policies. This might involve adding themselves to a privileged role or exploiting misconfigurations in existing roles.
3. Discovery: The attacker enumerates existing Conditional Access policies to identify targets for removal. They may focus on policies that enforce MFA or restrict access based on location.
4. Defense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.
5. Policy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a “Delete conditional access policy” event.
6. Credential Access: With the CA policy removed, the attacker may attempt to access sensitive resources or applications without MFA, potentially gaining access to credentials or sensitive data.
7. Persistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.
8. Lateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.

Impact

A successful removal of a Conditional Access policy can lead to widespread compromise. Attackers can bypass multi-factor authentication, gain unauthorized access to sensitive data, and escalate privileges within the organization. The impact can range from data breaches and financial losses to reputational damage and compliance violations. Depending on the scope of the compromised policy, the number of affected users could range from dozens to thousands.

Recommendation

• Deploy the provided Sigma rule to detect the “Delete conditional access policy” event in Azure audit logs, indicating a CA policy removal.
• Regularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.
• Implement multi-factor authentication for all user accounts, especially those with administrative privileges.
• Monitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.
• Investigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.
• Review and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.

Attack Chain

1. An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
2. The attacker attempts to establish persistence.
3. The attacker uses a script or program to create a new scheduled job within the C:\Windows\Tasks\ directory.
4. The scheduled job is configured to execute a malicious payload at a specified time or interval.
5. The malicious payload could be a script (e.g., PowerShell) or an executable.
6. The scheduled job executes, triggering the malicious payload.
7. The attacker maintains persistent access to the system.
8. The attacker performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to maintain a persistent presence on the compromised system. This allows them to execute malicious code, steal sensitive information, or perform other malicious activities over an extended period. The number of affected systems can vary depending on the scope of the initial compromise and the attacker’s objectives.

Recommendation

• Enable Sysmon Event ID 11 (File Create) logging to monitor file creation events on Windows systems.
• Deploy the Sigma rule “Detect Suspicious Scheduled Job Creation” to your SIEM and tune for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on scheduled jobs created in the C:\Windows\Tasks\ directory with a “.job” extension.
• Review and update exclusion lists for known legitimate scheduled job creation processes (e.g., CCleaner, ManageEngine) to minimize false positives.

Attack Chain

1. An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker modifies the SilentProcessExit registry key to specify a malicious process to be executed when a target application crashes. This involves setting the ReportingMode and Debugger values under the SilentProcessExit key for the target application.
3. The attacker triggers a crash in the target application or waits for a legitimate crash to occur.
4. WerFault.exe is invoked to handle the application crash.
5. Due to the registry modification, WerFault.exe spawns the attacker-controlled process, passing command-line arguments such as -s, -t, and -c.
6. The attacker-controlled process executes with the privileges of WerFault.exe, potentially achieving privilege escalation.
7. The malicious process performs actions such as injecting code into other processes, establishing persistence, or exfiltrating data.
8. The attacker achieves their objectives, such as maintaining persistence, escalating privileges, or evading detection.

Impact

A successful attack can lead to persistence, privilege escalation, and defense evasion. Attackers can use this technique to execute malicious code with elevated privileges, potentially bypassing security controls and gaining unauthorized access to sensitive data and system resources. The number of victims and affected sectors can vary depending on the attacker’s objectives and the scope of the initial compromise.

Recommendation

• Enable Sysmon process creation logging to capture WerFault.exe child processes (Data Source: Sysmon).
• Deploy the Sigma rule “WerFault Child Process Masquerading” to your SIEM and tune for your environment.
• Review the SilentProcessExit registry key for unauthorized modifications (registry_set event).
• Investigate any WerFault.exe processes with command-line arguments -s, -t, and -c (process_creation event).

Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker modifies the registry to create a new entry for a custom shim database. The registry path targeted is typically under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\.
3. The attacker writes a malicious .sdb file containing the custom shim database to a location on disk.
4. The registry entry created points to the malicious .sdb file.
5. When a targeted application is launched, Windows checks the AppCompatFlags registry keys.
6. The system loads the malicious shim database specified in the registry.
7. The malicious code within the shim database is executed in the context of the targeted application.
8. The attacker achieves persistence, as the malicious shim database is loaded every time the targeted application is run.

Impact

Successful exploitation allows attackers to maintain persistent access to the system, even after reboots or software updates. The injected code runs within the context of a legitimate process, which can evade detection by traditional security tools. This can lead to data theft, system compromise, or further malicious activities, such as lateral movement within the network. The use of application shimming for persistence affects systems running Windows and can impact organizations of any size or sector.

Recommendation

• Deploy the Sigma rule Detect Custom Shim Database Installation to your SIEM to identify suspicious registry modifications related to application shimming.
• Enable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function.
• Investigate any alerts generated by the Sigma rule, focusing on processes that are not in the exclusion list.
• Block or quarantine any identified malicious .sdb files to prevent further execution.
• Review and update the exclusion list in the Sigma rule with any newly identified legitimate applications that use shim databases, reducing false positives.

Attack Chain

1. The attacker sends a malicious HTTP POST request to a vulnerable Apache Struts endpoint (e.g., *.action).
2. The HTTP POST request contains a multipart/form-data content type with a WebKitFormBoundary string.
3. The request exploits CVE-2023-50164, leveraging a path traversal vulnerability in the file upload process.
4. The attacker bypasses security controls due to the path traversal vulnerability.
5. The attacker uploads a malicious JSP file (web shell) to a web-accessible directory, such as Tomcat’s webapps directory.
6. A Java process (e.g., Tomcat) creates the JSP web shell file in the webapps directory.
7. The attacker accesses the deployed web shell via HTTP.
8. The attacker executes arbitrary commands on the server through the web shell.

Impact

Successful exploitation of CVE-2023-50164 allows attackers to achieve remote code execution on the affected server. This can lead to complete system compromise, data exfiltration, deployment of malware, and lateral movement within the network. The vulnerability affects Apache Struts 2 applications using the file upload feature, potentially impacting numerous organizations across various sectors using the framework.

Recommendation

• Deploy the Sigma rule “Apache Struts CVE-2023-50164 Webshell Creation” to detect JSP file creation events in webapps directories following suspicious POST requests as described in the overview.
• Deploy the Sigma rule “Apache Struts CVE-2023-50164 Suspicious POST Request” to detect suspicious POST requests to Struts endpoints with multipart/form-data content containing WebKitFormBoundary, as indicated in the Attack Chain.
• Patch Apache Struts 2 to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability, as noted in the References.
• Enable HTTP request body capture in network traffic monitoring tools to detect the multipart/form-data content containing WebKitFormBoundary indicators, as required by the rule setup.

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. The attacker gains initial access to the target system, potentially through phishing or other social engineering methods (not detailed in source).
2. The attacker identifies a user with Microsoft Outlook installed and running on a Windows system.
3. The attacker modifies or replaces the existing VbaProject.OTM file located in the user’s Outlook profile (C:\Users\*\AppData\Roaming\Microsoft\Outlook\).
4. The modified VbaProject.OTM file contains malicious VBA code designed to execute when Outlook starts.
5. The victim launches Microsoft Outlook.
6. The malicious VBA code within VbaProject.OTM executes automatically upon Outlook startup, establishing persistence.
7. The VBA script can perform various malicious actions, such as downloading and executing additional payloads, establishing command and control, or exfiltrating data.

Impact

Successful exploitation can lead to persistent access to the compromised system, allowing attackers to steal sensitive information, deploy ransomware, or use the system as a staging ground for further attacks within the network. The number of victims and specific sectors targeted depends on the attacker’s objectives and scope of the campaign. If the attack succeeds, an attacker could gain complete control over the user’s email account and associated data, leading to significant data breaches and financial losses.

Recommendation

• Deploy the Sigma rule Detect Outlook VBA Template Modification to your SIEM to identify unauthorized modifications to the VbaProject.OTM file based on file creation events.
• Enable Sysmon file creation logging (Event ID 11) to activate the Detect Outlook VBA Template Modification rule.
• Implement application control policies to restrict unauthorized modifications to Outlook VBA files as described in the “Response and remediation” section of the source.
• Monitor file creation events related to VbaProject.OTM in the specified paths (C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM) as highlighted in the rule query.

Attack Chain

1. An attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.
2. The attacker attempts to create or modify a Role or ClusterRole.
3. The attacker adds high-risk permissions to the Role or ClusterRole, such as wildcard verbs/resources (*) or escalation verbs (bind, escalate, impersonate).
4. The Kubernetes API server authorizes the request, potentially due to misconfigured RBAC policies.
5. The attacker creates or modifies a RoleBinding or ClusterRoleBinding to associate the modified Role or ClusterRole with a target user, group, or service account.
6. The target user, group, or service account now possesses the elevated privileges granted by the modified Role or ClusterRole.
7. The attacker leverages the elevated privileges to perform unauthorized actions within the cluster, such as accessing sensitive data or deploying malicious workloads.
8. The attacker achieves persistence by maintaining the modified Role or ClusterRole and its associated bindings, allowing continued access to elevated privileges.

Impact

Successful exploitation can lead to significant security breaches within a Kubernetes environment. Attackers can gain unauthorized access to sensitive data, deploy malicious workloads, disrupt services, and potentially compromise the entire cluster. This can result in data breaches, financial losses, and reputational damage. The rule aims to prevent attackers from silently expanding privileges, enabling persistence, or facilitating lateral movement across the cluster.

Recommendation

• Deploy the Sigma rule Kubernetes Creation of Sensitive Role to your SIEM to detect the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions.
• Enable Kubernetes audit logging to capture the necessary events for the Sigma rules to function effectively (reference: Kubernetes audit logs in logsource).
• Implement RBAC guardrails using tools like OPA Gatekeeper or Kyverno to prevent the creation of Roles/ClusterRoles with wildcard or escalation verbs (reference: harden recommendation in the content).
• Regularly review and audit RBAC configurations to identify and remediate overly permissive roles and bindings.

Attack Chain

1. Initial Access: An attacker gains unauthorized access to an Azure Active Directory account with sufficient privileges, possibly via credential phishing or password spraying (T1078.004).
2. Privilege Escalation (if needed): The attacker escalates privileges within Azure AD if the initially compromised account lacks the necessary permissions to read BitLocker keys.
3. Discovery: The attacker uses Azure AD tools or PowerShell cmdlets to identify devices with BitLocker encryption enabled.
4. Key Retrieval: The attacker uses the Azure portal or PowerShell to retrieve the BitLocker recovery key for a specific device. This generates an audit log event.
5. Offline Access: The attacker uses the retrieved BitLocker recovery key to unlock the encrypted drive on a compromised system or a copied disk image.
6. Data Exfiltration or Lateral Movement: With the drive unlocked, the attacker can access sensitive data, install malware, or use the system for lateral movement within the network.

Impact

Successful BitLocker key retrieval can lead to unauthorized access to sensitive data stored on encrypted drives. This could result in data breaches, financial loss, reputational damage, and legal liabilities. The impact depends on the sensitivity and volume of data stored on the encrypted volumes, as well as the attacker’s subsequent actions.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect BitLocker key retrieval events in Azure Audit Logs.
• Review Azure AD access logs for suspicious activity related to user accounts that have permissions to read BitLocker keys (reference: Sigma rule).
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges in Azure AD, to prevent unauthorized access (T1078.004).
• Implement Conditional Access policies to restrict access to sensitive Azure resources, including BitLocker recovery keys, based on factors such as location, device, and user risk.
• Regularly review and audit Azure AD roles and permissions to ensure that users only have the necessary privileges to perform their job functions.

Attack Chain

1. An attacker gains initial access to a low-privileged Azure account, possibly through credential phishing or password reuse.
2. The attacker attempts to activate a privileged role (e.g., Global Administrator, Security Administrator) through Azure PIM.
3. The PIM request triggers an approval workflow, requiring authorization from designated approvers.
4. An attacker compromises an approver account, enabling them to approve their own malicious PIM request or deny a legitimate one.
5. Alternatively, an unwitting approver approves a malicious request, potentially due to social engineering.
6. Upon approval, the attacker’s account is temporarily elevated to the requested privileged role.
7. The attacker leverages the elevated privileges to perform malicious actions, such as creating new accounts, modifying security policies, or accessing sensitive data.
8. The attacker attempts to maintain persistence by creating backdoor accounts or modifying access controls, potentially circumventing PIM restrictions.

Impact

Successful exploitation can lead to full control over the Azure environment, potentially impacting hundreds or thousands of users and services. A compromised Global Administrator role grants the attacker the ability to access and modify all resources within the Azure tenant, leading to data breaches, service disruptions, and financial losses. The targeted sectors include any organization leveraging Azure PIM for privileged access management.

Recommendation

• Deploy the Sigma rule Azure PIM Elevation Approved or Denied to your SIEM to detect unusual PIM activity.
• Investigate any PIM approval or denial events occurring outside of normal business hours or originating from unexpected locations, focusing on the properties.message field in the logs.
• Implement multi-factor authentication (MFA) for all Azure accounts, especially those with approval permissions for PIM requests.
• Regularly review and audit PIM role assignments and approval workflows to ensure they align with the principle of least privilege.
• Enable alerting on changes to PIM policies and configurations to detect any unauthorized modifications.
• Monitor Azure Audit Logs for suspicious activity following PIM role activation, looking for actions associated with common attack techniques (e.g., account creation, policy modification).

Attack Chain

1. An attacker gains initial access to an Azure AD account, possibly through credential theft or phishing.
2. The attacker authenticates to the Azure portal or uses PowerShell with compromised credentials.
3. The attacker enumerates existing Azure AD roles and identifies potential targets like Global Administrator or Device Administrator.
4. The attacker uses the Add-AzureADGroupMember or similar cmdlets to add a compromised or newly created user account to the target role.
5. The Azure AD audit logs record the “Add member to role” operation with the specific role GUIDs (e.g., ‘7698a772-787b-4ac8-901f-60d6b08affd2’ or ‘62e90394-69f5-4237-9190-012177145e10’).
6. The newly added user account inherits the privileges associated with the Global Administrator or Device Administrator role.
7. The attacker leverages the elevated privileges to access sensitive data, modify configurations, or deploy malicious applications.
8. The attacker establishes persistent access by creating new administrative accounts or modifying existing ones to maintain control.

Impact

Successful addition of a user to a Global Administrator or Device Administrator role grants the attacker unrestricted access to the Azure AD tenant, potentially impacting all resources connected to it. This can lead to data breaches, service disruptions, financial losses, and reputational damage. The scope of the impact depends on the extent to which the attacker leverages the compromised privileges.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious additions of users to Global or Device Admin roles in Azure AD Audit Logs.
• Investigate any alerts generated by the Sigma rule, focusing on the context of the user account being added and the source of the role assignment operation.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of credential theft (T1078.004).
• Regularly review Azure AD role assignments to identify and remove any unauthorized or unnecessary privileges.
• Monitor for other suspicious Azure AD activity, such as unusual sign-in patterns, application registrations, and resource deployments.

Attack Chain

1. The attacker compromises or creates a malicious SAML identity provider.
2. The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
3. The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
4. The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
5. AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
6. The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
7. The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
8. The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

Successful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.

Recommendation

• Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
• Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
• Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
• Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
• Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

Attack Chain

1. An attacker gains initial access to the system through methods such as phishing or exploiting vulnerabilities.
2. The attacker establishes persistence on the compromised system.
3. The attacker identifies the specific registry keys controlling Outlook security settings, located under \SOFTWARE\Microsoft\Office\Outlook\Security\.
4. The attacker uses a command-line tool or script (e.g., reg.exe, PowerShell) to modify the registry values related to Outlook security settings.
5. Specifically, values are modified to enable the execution of “unsafe” mail client rules, potentially allowing arbitrary code execution via crafted emails.
6. The attacker crafts a malicious email designed to trigger the newly enabled, unsafe mail rules.
7. Upon receiving the email, Outlook processes the rules, executing the attacker’s payload.
8. The attacker achieves code execution, enabling further malicious activities, such as data exfiltration or lateral movement within the network.

Impact

Successful modification of Outlook security settings allows attackers to execute arbitrary code within the context of the user account running Outlook. This can lead to the compromise of sensitive information contained within emails, the installation of malware, and further propagation of the attack throughout the organization. The scope of the impact depends on the privileges of the user account and the attacker’s objectives, potentially affecting all users within an organization if the attacker gains domain administrator access.

Recommendation

• Deploy the Sigma rule “Outlook Security Settings Updated - Registry” to your SIEM to detect unauthorized modifications to Outlook security-related registry keys (logsource: registry_set/windows).
• Monitor process creation events for suspicious processes (e.g., reg.exe, powershell.exe) modifying registry keys under \SOFTWARE\Microsoft\Office\Outlook\Security\ (Sigma rule below, logsource: process_creation/windows).
• Implement strict application control policies to prevent unauthorized execution of scripts and executables that could be used to modify registry settings.

Attack Chain

1. An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker creates or modifies a scheduled task to execute a malicious payload. This task is designed to run at a specific time or event.
3. The Windows Task Scheduler service (svchost.exe with “Schedule” argument) initiates the scheduled task.
4. The scheduled task executes a suspicious executable, such as powershell.exe, cmd.exe, or mshta.exe.
5. The suspicious executable is launched from an unusual or suspicious path, such as C:\\Users\\, C:\\ProgramData\\, or C:\\Windows\\Temp\\.
6. The executed payload performs malicious activities, such as downloading additional malware, establishing persistence, or exfiltrating data.
7. The attacker maintains persistence on the system through the scheduled task, allowing for repeated execution of the malicious payload.

Impact

Successful exploitation allows attackers to maintain persistent access to the compromised system, execute malicious code, and potentially escalate privileges. This can lead to data theft, system compromise, and further lateral movement within the network. The damage includes potential data exfiltration, malware installation, and disruption of normal system operations.

Recommendation

• Enable process creation logging with command line arguments to detect suspicious executions (logs-endpoint.events.process-* and logs-windows.sysmon_operational-*).
• Deploy the Sigma rule “Suspicious Execution via Scheduled Task” to your SIEM to identify potentially malicious processes executed via scheduled tasks. Tune the rule to exclude legitimate software installations or updates (see rule section below).
• Investigate any alerts generated by the Sigma rule, focusing on processes with suspicious original file names and command line arguments (process.pe.original_file_name, process.args).
• Monitor scheduled tasks for unauthorized modifications or additions, as this is a common technique for persistence (registry_set).

Attack Chain

1. An attacker gains initial access to a compromised account with sufficient privileges to modify user rights.
2. The attacker assigns the SeEnableDelegationPrivilege to a target account using tools like ntrights.exe or PowerShell cmdlets.
3. Windows Security Event 4704 is generated, logging the privilege assignment.
4. The attacker modifies the target account’s attributes, such as userAccountControl or msDS-AllowedToDelegateTo, to enable delegation.
5. The attacker leverages Kerberos delegation to impersonate other users or services.
6. Using the impersonated credentials, the attacker accesses sensitive resources or performs privileged actions.
7. The attacker moves laterally within the network, compromising additional systems and accounts.
8. The attacker achieves their final objective, such as data exfiltration or domain dominance.

Impact

Successful exploitation allows attackers to compromise Active Directory accounts and elevate privileges, potentially leading to full control over the domain. The impact includes unauthorized access to sensitive data, lateral movement to critical systems, and the potential for long-term persistence. Depending on the compromised accounts, the entire organization can be at risk.

Recommendation

• Enable “Audit Authorization Policy Change” to generate Windows Security Event ID 4704 (Setup instructions: https://ela.st/audit-authorization-policy-change).
• Deploy the Sigma rule “Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal” to your SIEM to detect the assignment of this privilege.
• Investigate any instances where SeEnableDelegationPrivilege is assigned, focusing on the targeted account and the source of the change.
• Monitor for modifications to delegation-related attributes on user and computer objects.

Attack Chain

1. The attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.
2. The attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.
3. The attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.
4. The malicious webhook is deployed to the cluster, configured to modify pod specifications.
5. When new pods are created, the webhook injects a malicious container into the pod specification before deployment.
6. The malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.
7. Alternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.
8. The webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.

Impact

Compromising the Kubernetes Admission Controller can lead to persistent access within the cluster. The attacker can inject malicious containers into numerous pods, potentially affecting all applications deployed in the cluster. Sensitive information, like secrets, can be stolen, enabling lateral movement and privilege escalation within the Azure environment. The impact ranges from data breaches to complete cluster compromise.

Recommendation

• Deploy the Sigma rule “Azure Kubernetes Admission Controller Configuration Change” to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.
• Regularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.
• Implement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.
• Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO and MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO operations to identify potential abuse.

Attack Chain

1. Initial Compromise (Optional): An attacker gains initial access to an Azure AD account through compromised credentials or other means.
2. Privilege Escalation (Optional): The attacker escalates privileges to an account with sufficient permissions to manage TAPs.
3. TAP Generation: The attacker, using an account with appropriate permissions, generates a temporary access pass (TAP) for a target account.
4. TAP Activation: The attacker uses the TAP to authenticate to the target account.
5. Resource Access: Once authenticated, the attacker gains access to resources and applications associated with the target account.
6. Lateral Movement (Optional): The attacker uses the compromised account to access other resources or accounts within the environment.
7. Persistence (Optional): The attacker establishes persistence by creating new credentials or modifying existing ones, if permissions allow.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, systems, and applications within the Azure environment. Compromised privileged accounts can grant attackers control over critical infrastructure, leading to data breaches, service disruptions, and reputational damage. The impact depends on the permissions associated with the compromised account and the resources accessible through the TAP.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect TAP additions in Azure AD audit logs (see rules).
• Investigate any instances where TAPs are added to privileged accounts in Azure AD, as highlighted in the rule description and references.
• Review Azure AD audit logs for suspicious activity surrounding the TAP generation event, including the source IP address and user agent (see rules).
• Monitor for anomalous sign-in activity using TAPs, specifically focusing on unusual locations or devices.

Attack Chain

1. The attacker gains initial access via an unknown vector.
2. A batch script is executed on the target system.
3. The batch script uses choice.exe with the /T and /N parameters to introduce a time delay. The /T parameter specifies a timeout period, and the /N parameter suppresses the display of choices.
4. This delay allows the malware to evade time-sensitive detection mechanisms.
5. After the delay, the script executes further commands, potentially downloading and executing a payload.
6. The payload executes, installing a keylogger such as SnakeKeylogger or 0bj3ctivity Stealer.
7. The keylogger captures sensitive information such as keystrokes and clipboard data.
8. The stolen data is exfiltrated to a remote server.

Impact

Compromised systems can lead to data theft, intellectual property loss, and financial fraud. SnakeKeylogger and similar malware have been used to steal credentials and sensitive information from various targets. Successful exploitation could result in significant financial losses, reputational damage, and legal liabilities. The number of victims and the extent of the damage depend on the attacker’s objectives and the compromised systems’ value.

Recommendation

• Deploy the Sigma rule Detect Choice.exe Time Delay to your SIEM to detect the use of choice.exe with time-delay parameters (log source: process_creation).
• Enable Sysmon process creation logging (Event ID 1) to capture the necessary process execution data for the Sigma rule.
• Investigate any instances of choice.exe being used with the /T and /N parameters to determine if it is part of a malicious script.
• Block the execution of unsigned or untrusted batch scripts to prevent the initial execution of the malicious code.
• Monitor endpoint activity for suspicious processes and network connections originating from systems where choice.exe has been detected.

Attack Chain

1. The attacker gains initial access to the system, typically through phishing, exploiting vulnerabilities, or using stolen credentials (not covered in the source).
2. The attacker modifies the Windows Registry Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run or HKLM\Software\Microsoft\Windows\CurrentVersion\Run) to execute a malicious program or script.
3. The system starts, and the winlogon.exe process initiates userinit.exe.
4. userinit.exe starts explorer.exe, loading the user’s profile and desktop environment.
5. The Registry Run keys are processed, and the malicious program or script is executed as a child process of explorer.exe. This often involves suspicious processes like cscript.exe, powershell.exe, or rundll32.exe.
6. The malicious process executes from a suspicious location, such as C:\\Users\\*, C:\\ProgramData\\*, or C:\\Windows\\Temp\\*.
7. The malicious process performs its intended actions, such as downloading additional malware, establishing command and control, or exfiltrating data.
8. The system remains infected, with the malicious process running every time the user logs on, ensuring persistence.

Impact

A successful attack can lead to persistent malware infections, data theft, and complete system compromise. Attackers can maintain long-term access to the compromised system, potentially leading to further lateral movement within the network. This can result in significant financial losses, reputational damage, and operational disruptions.

Recommendation

• Deploy the Sigma rule “Persistent Suspicious Program Execution” to detect suspicious processes executed shortly after user logon (rule).
• Enable process creation logging via Sysmon or Elastic Defend to provide the data required for the Sigma rule to function effectively.
• Investigate any alerts generated by the Sigma rule by examining the process lineage and command-line arguments of the suspicious processes.
• Implement strict access controls and regularly audit user accounts to prevent unauthorized modifications to the Registry Run keys.
• Block execution of the listed suspicious processes (cscript.exe, wscript.exe, PowerShell.EXE, MSHTA.EXE, RUNDLL32.EXE, REGSVR32.EXE, RegAsm.exe, MSBuild.exe, InstallUtil.exe) from suspicious paths (C:\\Users\\*, C:\\ProgramData\\*, C:\\Windows\\Temp\\*) via application control policies (overview).

Attack Chain

1. An attacker gains initial access to a user’s credentials through phishing, credential stuffing, or malware.
2. The attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.
3. The attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.
4. The attacker initiates a password reset request using the “Forgot password” feature or a similar mechanism.
5. Azure AD sends a password reset verification code or link to the user’s registered email address or phone number.
6. If the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.
7. The attacker uses the verification code or link to set a new password for the user’s Azure AD account.
8. The attacker logs in to the Azure AD account with the new password, gaining unauthorized access.

Impact

Successful password resets by attackers can lead to complete account takeover, allowing them to access sensitive data, resources, and systems protected by Azure AD. This can result in data breaches, financial loss, reputational damage, and disruption of business operations. The impact depends on the privileges and permissions assigned to the compromised account.

Recommendation

• Deploy the Sigma rule Password Reset By User Account to your SIEM to detect user-initiated password resets in Azure AD audit logs.
• Investigate any detected password resets, especially those initiated by users who have not recently requested a password change.
• Review and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.
• Monitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.

Attack Chain

1. The attacker gains initial access to the system, often through phishing, exploiting a vulnerability, or compromised credentials.
2. The attacker executes arbitrary code on the compromised system.
3. The attacker uploads or creates malicious files (e.g., backdoors, scripts) on the system.
4. The attacker uses attrib.exe with the “+h” flag to hide these malicious files and directories, evading detection. Example: attrib +h C:\Windows\Temp\evil.exe
5. The attacker may also hide associated log files or other artifacts to further conceal their activities.
6. The attacker establishes persistence, ensuring continued access even after system reboots.
7. The attacker moves laterally within the network, compromising additional systems and escalating privileges.
8. The attacker achieves their objective, which may include data theft, ransomware deployment, or espionage.

Impact

Successful exploitation allows attackers to hide malicious files and directories, hindering incident response and forensic investigations. This can lead to prolonged periods of undetected malicious activity, increasing the risk of data breaches, financial loss, and reputational damage. The consequences can range from minor disruptions to significant operational impact, depending on the attacker’s objectives and the scope of the compromise.

Recommendation

• Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious usage of attrib.exe with the ‘+h’ flag.
• Enable process-creation logging with command-line arguments on Windows endpoints to ensure the detection rules can be effectively applied (Sysmon Event ID 1 or Windows Event Log Security 4688).
• Investigate any alerts generated by the Sigma rules, paying close attention to the parent processes and the context in which attrib.exe is being executed.
• Implement file integrity monitoring (FIM) on critical system directories to detect unauthorized file modifications, including attribute changes.

Attack Chain

1. An attacker gains initial access to a system.
2. The attacker creates a malicious script (e.g., VBScript, PowerShell) designed to execute arbitrary commands.
3. The attacker identifies the Startup folder path for a specific user or all users.
4. The attacker creates a shortcut file (e.g., .lnk) or a script file directly within the Startup folder.
5. The shortcut or script is configured to execute the malicious script.
6. The system is restarted or the user logs in.
7. The operating system automatically executes the script located in the Startup folder.
8. The malicious script executes, allowing the attacker to perform actions such as installing malware, establishing persistence, or exfiltrating data.

Impact

A successful attack leveraging the Startup folder persistence mechanism allows the attacker to maintain unauthorized access to a compromised system. This can lead to the execution of malicious code, installation of malware, data theft, and further compromise of the network. The impact is significant, potentially affecting all users who log into the system.

Recommendation

• Deploy the Sigma rule “Detect Script Creation in Startup Directory” to your SIEM and tune for your environment to identify the creation of suspicious scripts in the Startup folder.
• Deploy the Sigma rule “Detect Script Execution via Startup Directory” to your SIEM and tune for your environment to identify script execution from the Startup directory.
• Enable Sysmon Event ID 11 (File Create) to collect necessary data for the detections above.
• Investigate any alerts generated by these rules promptly to identify and remediate potential persistence attempts.
• Block the file extensions listed in the rule query (vbs, vbe, wsh, wsf, js, jse, sct, hta, ps1, bat, cmd) from being written to the startup folder via application control policies where possible.

Attack Chain

1. An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability or using compromised credentials.
2. The attacker identifies cron job directories, such as /etc/cron.d/ or /var/spool/cron/crontabs/.
3. The attacker creates a new cron file within one of these directories.
4. The cron file contains malicious commands or scripts designed to execute at a specific time or interval. This could include commands to download and execute malware or establish a reverse shell.
5. The cron daemon automatically executes the commands specified in the newly created cron file according to the defined schedule.
6. The attacker gains persistent access to the system, allowing them to maintain control even after reboots.
7. The attacker may escalate privileges by scheduling commands that run with elevated permissions.
8. The attacker uses the persistent access to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation can grant attackers persistent access to compromised Linux systems, potentially leading to privilege escalation and unauthorized execution of arbitrary code. This can lead to data breaches, system compromise, and disruption of services. The impact is magnified if the compromised system has access to sensitive information or critical infrastructure.

Recommendation

• Deploy the Sigma rule “Detect New Cron File Creation” to your SIEM to detect the creation of cron files in cron directories and tune for your environment.
• Monitor file creation events in cron directories such as /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/, /etc/cron.weekly/, /var/spool/cron/crontabs/, and /var/spool/cron/root using file_event logs.
• Baseline normal cron file creation activity and apply additional filters to reduce false positives based on the specific environment, as mentioned in the rule description.

Attack Chain

1. Initial Compromise: The attacker gains initial access to an account with sufficient privileges to view PIM settings.
2. Discovery: The attacker enumerates existing PIM role settings within the Azure Active Directory environment.
3. Modification: The attacker modifies existing PIM role settings, such as extending the maximum activation time or removing approval requirements, using the Azure portal, PowerShell, or the Azure CLI.
4. Privilege Escalation: By modifying PIM settings, the attacker escalates their privileges, granting themselves elevated access to sensitive resources or administrative functions.
5. Persistence: The attacker establishes persistence by creating new or modifying existing role assignments to maintain access even if their initial account is compromised.
6. Lateral Movement: With escalated privileges, the attacker moves laterally to access other resources or accounts within the Azure environment.
7. Data Exfiltration/Impact: The attacker leverages their escalated privileges to exfiltrate sensitive data, disrupt services, or cause other damage.

Impact

Successful modification of PIM settings can have severe consequences, including unauthorized access to sensitive data, disruption of critical services, and privilege escalation leading to complete compromise of the Azure environment. A single compromised PIM setting can affect multiple users and resources, amplifying the impact of the attack. Early detection of PIM setting modifications can prevent attackers from gaining a foothold and causing significant damage.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect changes to PIM settings based on the properties.message field within Azure audit logs.
• Regularly review Azure audit logs for events related to PIM configuration changes, paying close attention to the user accounts making the changes and the scope of the modifications.
• Implement multi-factor authentication (MFA) for all accounts with privileges to manage PIM settings.
• Enforce the principle of least privilege by granting users only the minimum permissions required to perform their job functions.
• Establish a baseline of normal PIM settings and alert on any deviations from this baseline.
• Investigate any alerts triggered by the Sigma rule by correlating them with other security events and user activity.
• Implement automated responses to detected PIM setting modifications, such as disabling the affected user account or reverting the changes.

Attack Chain

1. An attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.
2. The attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.
3. The attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.
4. Azure Activity Logs record the “Add service principal” event.
5. The attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.
6. The attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.
7. The service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.

Impact

Successful creation and misuse of a service principal can lead to unauthorized access to sensitive data, resources, and services within the Azure environment. The impact can range from data breaches and service disruption to complete control over the Azure subscription, potentially affecting hundreds or thousands of resources and users. The attacker can leverage the compromised service principal to perform actions with the permissions assigned to it, leading to significant damage and financial loss.

Recommendation

• Deploy the Sigma rule “Azure Service Principal Created” to your SIEM and tune for your environment to detect suspicious service principal creations.
• Investigate any alerts generated by the “Azure Service Principal Created” rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.
• Review and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.
• Implement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.

Attack Chain

1. Initial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.
2. The attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.
3. The attacker disassociates the existing, legitimate directory using DisassociateDirectory.
4. The attacker associates a malicious directory they control using AssociateDirectory. This malicious directory is configured to impersonate legitimate users.
5. Alternatively, the attacker disables external IdP configuration for the directory using DisableExternalIdPConfigurationForDirectory.
6. The attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using EnableExternalIdPConfigurationForDirectory.
7. The attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.
8. The attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.

Impact

Successful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.
• Investigate any detected events related to AssociateDirectory, DisableExternalIdPConfigurationForDirectory, DisassociateDirectory, or EnableExternalIdPConfigurationForDirectory in AWS CloudTrail logs.
• Implement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.
• Review and restrict IAM permissions to minimize the blast radius of compromised credentials.
• Monitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.

Attack Chain

1. An attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.
2. The attacker installs and configures S3 Browser on a compromised host or uses an existing installation.
3. The attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.
4. The attacker uses S3 Browser to execute the CreateUser API call within AWS IAM.
5. The attacker configures the new IAM user with elevated privileges, potentially granting administrator access.
6. Alternatively, the attacker uses S3 Browser to execute the CreateAccessKey API call for an existing IAM user.
7. The attacker uses the newly created access key to perform actions within the AWS environment.
8. The attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.

Impact

Successful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.

Recommendation

• Deploy the Sigma rule “AWS IAM S3Browser User or AccessKey Creation” to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.
• Investigate any instances of CreateUser or CreateAccessKey events in AWS CloudTrail logs where the userAgent contains “S3 Browser”.
• Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.
• Review and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.

Attack Chain

1. The attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.
2. The attacker navigates to the Azure Active Directory portal.
3. The attacker locates a target application registration.
4. The attacker modifies the application’s URI settings, such as the reply URLs or identifier URIs.
5. The attacker configures the URI to point to a malicious server or a phishing page.
6. Users or applications are redirected to the malicious URI when attempting to authenticate or access the application.
7. The attacker intercepts credentials or performs other malicious actions.
8. The attacker establishes persistence by maintaining control over the application’s URI settings.

Impact

A successful attack could lead to credential theft, data breaches, or unauthorized access to sensitive resources. By compromising application URIs, attackers can redirect users to phishing pages, intercept credentials, or gain a foothold in the environment for further exploitation. This activity can be difficult to detect and can have a significant impact on the organization’s security posture.

Recommendation

• Deploy the Sigma rule Application URI Configuration Changes to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.
• Investigate any alerts generated by the Sigma rule Application URI Configuration Changes to determine if the URI modification is legitimate or malicious.
• Monitor Azure Audit Logs for any changes to application URI settings (as indicated by properties.message: Update Application Sucess- Property Name AppAddress) and validate the legitimacy of the changes.

Attack Chain

1. An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.
2. The attacker opens a command prompt or PowerShell session.
3. The attacker uses net.exe or net1.exe to create a new user account. The command includes the user argument along with /add or /ad flags. For example: net user <username> <password> /add.
4. The attacker may add the newly created user to privileged groups, such as Administrators or Domain Admins, to elevate privileges.
5. The attacker uses the new account to move laterally within the network, accessing sensitive data or systems.
6. The attacker establishes persistence by configuring the new account to be a service account or adding it to local administrator groups.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and long-term persistence on compromised systems. The impact is often determined by the privileges assigned to the newly created account. If the attacker adds the account to the Administrators group, they can effectively take full control of the affected system. In a domain environment, creating a domain account can lead to wider compromise across the entire network.

Recommendation

• Enable Sysmon process-creation logging to capture the necessary events for the rules below.
• Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
• Investigate any instances of net.exe or net1.exe creating user accounts, especially when initiated by unusual parent processes.
• Monitor for newly created accounts being added to privileged groups.
• Review the triage and analysis steps in the rule’s original documentation for guidance on investigating and responding to potential incidents.

Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker executes a command shell (e.g., cmd.exe, powershell.exe) on the compromised system.
3. The attacker uses the command shell to write a malicious executable or script file to one of the Windows Startup folders (C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\* or C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*).
4. The attacker modifies the file attributes (e.g., using attrib.exe) to hide the file or make it more difficult to detect.
5. The attacker schedules a reboot or waits for the user to log off and back on.
6. Upon user logon, the malicious executable or script in the Startup folder is automatically executed.
7. The malicious code establishes persistence, potentially downloading additional payloads or establishing a command and control (C2) channel.
8. The attacker maintains persistent access to the compromised system, enabling further malicious activities such as data theft or lateral movement.

Impact

Successful exploitation leads to persistent access on the compromised system, allowing attackers to maintain their foothold even after system reboots. This can lead to data exfiltration, installation of ransomware, or further propagation within the network. The number of affected systems depends on the scope of the initial compromise and the attacker’s ability to move laterally. Sectors commonly targeted by persistence techniques include finance, healthcare, and government.

Recommendation

• Enable Sysmon Event ID 11 (File Create) to capture file creation events, as referenced in the setup instructions.
• Deploy the Sigma rule Suspicious Process Writing to Startup Folder to your SIEM to detect suspicious processes creating files in the startup folder, and tune for your environment.
• Investigate any alerts generated by the Sigma rule to determine if the activity is malicious, referencing the investigation guide.
• Block the processes listed in the rule (cmd.exe, powershell.exe, etc.) from writing to the startup folders if legitimate use is not required.

Attack Chain

1. Initial Access: An attacker gains initial access to the target system through unspecified means.
2. Identify COM Objects: The attacker identifies suitable COM objects for abuse.
3. Modify Registry: The attacker modifies the registry to set the RunAs value for the selected COM object to Interactive User. This involves modifying the registry path HKCR\AppID\{Clsid}\RunAs.
4. Trigger COM Object Execution: The attacker triggers the execution of the modified COM object, potentially through a remote procedure call or other inter-process communication mechanisms.
5. Authentication Coercion: The execution of the COM object triggers NTLM authentication to a system controlled by the attacker.
6. Relay Attack: The attacker relays the coerced NTLM authentication to gain access to other resources on the network.
7. Session Hijacking: Successful relay leads to session hijacking, allowing the attacker to impersonate the user.
8. Lateral Movement/Privilege Escalation: The attacker uses the hijacked session for lateral movement or privilege escalation within the network.

Impact

A successful RemoteMonologue attack can lead to unauthorized access to sensitive systems and data. By coercing authentication and hijacking sessions, attackers can bypass security controls and escalate their privileges within the network. The scope of the impact depends on the privileges of the hijacked user account and the resources accessible to that account. This attack can enable lateral movement, data exfiltration, and other malicious activities.

Recommendation

• Deploy the Sigma rule Detect RemoteMonologue Registry Modification to your SIEM to identify suspicious registry modifications related to COM object hijacking.
• Enable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively.
• Investigate any alerts generated by the Sigma rule by reviewing the registry event logs and identifying the user account and process responsible for the registry modification.
• Implement enhanced monitoring on critical systems to detect any attempts to modify COM object registry settings.
• Block the attack by ensuring “RunAs” value is not set to “Interactive User”.

Attack Chain

1. An attacker gains initial access to a network via compromised credentials or exploiting a vulnerability.
2. The attacker performs network reconnaissance to identify target systems for lateral movement.
3. Using valid credentials or pass-the-hash techniques, the attacker authenticates to a remote Windows host over the network (e.g., SMB).
4. The attacker attempts to install a new service on the remote host, potentially using tools like sc.exe or PowerShell.
5. The service installation event is logged with a specific LogonId that matches the earlier network logon event, indicating a relationship between the two activities.
6. The newly installed service is configured to execute a malicious payload or establish a reverse shell.
7. The attacker uses the service to execute commands or deploy further malicious tools on the compromised host.
8. The attacker achieves persistence and lateral movement within the network, enabling further compromise and data exfiltration.

Impact

A successful attack using this technique can lead to widespread compromise of systems within a network. Attackers can use the newly installed service to execute arbitrary code, install malware, or move laterally to other systems. This can result in data theft, system disruption, or ransomware deployment. The impact can be significant, potentially affecting numerous systems and causing substantial financial and reputational damage.

Recommendation

• Enable Windows Security Event Logs with necessary auditing policies, specifically Audit Logon and Audit Security System Extension, to capture relevant logon and service installation events.
• Deploy the provided Sigma rules to your SIEM to detect suspicious remote service installations based on matching LogonIds from network logons.
• Investigate any alerts generated by the Sigma rules, focusing on unusual service file paths and user accounts.
• Review the list of excluded service file paths in the Sigma rules and customize them based on your environment’s known legitimate services.
• Monitor network connections for suspicious SMB activity, particularly connections originating from unusual or untrusted sources.
• Implement multi-factor authentication (MFA) to reduce the risk of credential theft and unauthorized network access.

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 a system, possibly through phishing or exploiting a vulnerability.
2. The attacker attempts to enable the AT command by modifying the registry.
3. The registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt is modified to a value of “1” or “0x00000001”.
4. The attacker uses the AT command to schedule a malicious task.
5. The scheduled task executes a command or script, such as downloading and executing malware.
6. The malware establishes persistence on the system.
7. The attacker uses the compromised system as a pivot point for lateral movement.

Impact

Enabling the AT command can lead to unauthorized task scheduling, malware execution, persistence, and lateral movement within a network. Successful exploitation can compromise sensitive data, disrupt operations, and grant attackers persistent access to critical systems. The use of a deprecated command makes it harder to detect, increasing the impact.

Recommendation

• Monitor registry events for modifications to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt as described in the rule overview.
• Deploy the Sigma rule “Scheduled Tasks AT Command Enabled” to your SIEM and tune for your environment.
• Enable Sysmon process creation and registry event logging to activate the rule.
• Investigate any alerts triggered by the Sigma rule “Scheduled Tasks AT Command Enabled” for suspicious activity.

Attack Chain

1. An attacker gains initial access to a Windows system, possibly through phishing or exploiting a software vulnerability.
2. The attacker elevates privileges to administrator or SYSTEM level, required to modify the trusted root certificate store.
3. The attacker uses tools like certutil.exe or PowerShell to import a malicious root certificate into the Windows registry.
4. The registry keys HKLM\Software\Microsoft\SystemCertificates\Root\Certificates or HKLM\Software\Policies\Microsoft\SystemCertificates\Root\Certificates are modified to add the new certificate.
5. The attacker uses the newly installed root certificate to sign malicious executables or scripts.
6. The signed malicious files are executed, bypassing signature-based detection mechanisms.
7. The attacker intercepts and decrypts SSL traffic, collecting sensitive data like credentials or financial information.
8. The attacker maintains persistence by using the trusted certificate to repeatedly sign and execute malicious code.

Impact

Successful installation of a malicious root certificate allows attackers to bypass security controls, leading to the execution of arbitrary code and potential data theft. This can result in significant data breaches, financial losses, and reputational damage. Attackers can use this technique to maintain a long-term presence on compromised systems, making detection and remediation more challenging. While no specific victim counts are available, the technique is broadly applicable across many sectors and can affect any organization running Windows systems.

Recommendation

• Deploy the Sigma rule “Detect Root Certificate Modification” to your SIEM to detect registry modifications related to root certificate installation.
• Enable Sysmon registry event logging to provide the necessary data for the Sigma rule.
• Investigate any alerts triggered by the Sigma rule, focusing on processes modifying the registry keys related to root certificates.
• Review the “False Positives” section in the rule documentation to tune the Sigma rule for your environment.
• Monitor network traffic for suspicious SSL decryption activity following the detection of a root certificate modification.

Attack Chain

1. Initial Access: The attacker gains initial access to the system through methods such as phishing, exploiting vulnerabilities, or compromised credentials.
2. Privilege Escalation: The attacker escalates privileges to obtain necessary permissions for modifying file and directory access rights. This can be achieved through exploiting system vulnerabilities or using stolen credentials with elevated privileges.
3. Tool Deployment: The attacker deploys or utilizes existing system tools like icacls.exe, cacls.exe, or xcacls.exe to modify access control lists (ACLs) on files and directories.
4. Access Rights Modification: The attacker uses the deployed tools to modify the ACLs of critical system files or directories, potentially granting themselves full control or restricting access for legitimate users and security software. Specific command-line arguments like *:R*, *:W*, *:F*, *:C*, *:N*, */P*, and */E* are used to manipulate access rights.
5. Defense Evasion: By modifying access rights, the attacker attempts to evade detection by security software and hinders incident response efforts by restricting access to forensic data or security tools.
6. Persistence: The attacker establishes persistence by modifying the access rights of startup scripts or registry keys, ensuring that their malicious code executes even after system reboots.
7. Lateral Movement: The attacker uses the modified access rights to access files and directories on other systems within the network, facilitating lateral movement and further compromise.
8. Impact: The attacker achieves their final objective, such as data exfiltration, system disruption, or deploying ransomware, by leveraging the modified access rights to access and manipulate sensitive data or critical system resources.

Impact

Successful exploitation allows attackers to persist on the system, evade detection, and potentially move laterally within the network. Modification of file and directory permissions can hinder investigation, impede remediation efforts, and maintain persistent access to the compromised environment. The impact ranges from data theft to complete system compromise and denial of service. This activity is often associated with APT groups and coinminer operations.

Recommendation

• Enable Sysmon process creation logging (Event ID 1) to capture the execution of icacls.exe, cacls.exe, and xcacls.exe.
• Deploy the Sigma rule “Detect Suspicious Icacls Usage” to your SIEM to identify instances of access right modifications via icacls.exe, cacls.exe, and xcacls.exe.
• Investigate any instances where these tools are used to modify access rights, especially when command-line arguments include *:R*, *:W*, *:F*, *:C*, *:N*, */P*, and */E*.
• Monitor Windows Event Log Security (4688) for process creation events to correlate with Sysmon data.

Attack Chain

1. The attacker gains initial access to the system through unspecified means.
2. The attacker attempts to modify the Windows Error Reporting ReflectDebugger registry key.
3. The attacker modifies the ReflectDebugger value within one of the following registry paths: HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, \REGISTRY\MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, or MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger.
4. The attacker sets the ReflectDebugger value to a malicious executable or script.
5. The attacker triggers Werfault.exe with the -pr parameter, either manually or through a system event.
6. Werfault.exe executes the attacker-controlled code specified in the ReflectDebugger registry value.
7. The attacker achieves persistence, as the malicious code is executed each time Werfault is triggered with the -pr parameter.

Impact

Successful exploitation allows attackers to achieve persistence on the targeted system. This can lead to the execution of arbitrary code, potentially resulting in data theft, further malware installation, or complete system compromise. The impact is limited by the permissions of the Werfault process. While no specific victim counts are available, this technique can affect any Windows system where the attacker can modify the registry.

Recommendation

• Deploy the Sigma rule Werfault ReflectDebugger Registry Modification to detect unauthorized modifications to the ReflectDebugger registry key (logsource: registry_set, rule title).
• Enable Sysmon process creation logging to detect the execution of Werfault with the -pr parameter.
• Monitor registry events for changes to the specific ReflectDebugger paths mentioned in the overview section (HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger).

Attack Chain

1. Initial compromise of a low-privileged user account through phishing or credential theft.
2. Lateral movement to a system with access to Active Directory management tools.
3. Privilege escalation to an account with permissions to modify group memberships (e.g., leveraging exploits or credential dumping).
4. Use of AD management tools (e.g., Active Directory Users and Computers, PowerShell with AD module) to add the attacker-controlled user account to a privileged group, such as Domain Admins (RID 512).
5. The attacker logs in with the newly privileged account.
6. The attacker uses their elevated privileges to access sensitive data, install backdoors, or perform other malicious activities.
7. The attacker may attempt to remove the initially compromised account to remove traces of their activities.

Impact

Successful addition of an attacker-controlled user to a privileged AD group grants them near-total control over the domain. This can lead to widespread data breaches, ransomware deployment across the entire network, compromise of sensitive systems, and long-term disruption of business operations. The impact can extend to all domain-joined systems and resources, potentially affecting thousands of users and devices. Remediation often requires a complete rebuild of the Active Directory environment, resulting in significant downtime and financial losses.

Recommendation

• Enable “Audit Security Group Management” in Active Directory to generate the necessary security events for detecting group membership changes.
• Deploy the Sigma rule “User Added to Privileged Group in Active Directory” to your SIEM to detect suspicious additions to privileged groups, tuning the rule for known administrative accounts.
• Monitor for unexpected use of AD management tools, such as Active Directory Users and Computers or PowerShell with the AD module, especially from unusual source hosts.
• Investigate any alerts generated by the Sigma rule by verifying the legitimacy of the user adding members to the group and validating the need for the new member to have those privileges.
• Regularly review the membership of privileged groups and remove any unauthorized or unnecessary accounts.

Attack Chain

1. An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
2. The attacker enumerates existing scheduled tasks on the system using tools like schtasks.exe or PowerShell cmdlets.
3. The attacker identifies a suitable scheduled task to modify for persistence.
4. The attacker modifies the task’s settings, such as the trigger time, the executable to run, or the arguments passed to the executable. This modification is logged as event ID 4702.
5. The scheduled task is updated using schtasks.exe /change or PowerShell’s Set-ScheduledTask cmdlet.
6. The modified scheduled task executes at the specified time, launching the attacker’s malicious payload.
7. The malicious payload establishes a reverse shell to the attacker’s command and control (C2) server.
8. The attacker uses the reverse shell to perform further actions on the compromised system, such as data exfiltration or lateral movement.

Impact

A successful attack involving the modification of scheduled tasks can lead to persistent access to a compromised system. The attacker can use this access to steal sensitive data, install malware, or perform other malicious activities. While this rule is low severity, it can uncover attackers attempting to persist in a network.

Recommendation

• Enable “Audit Other Object Access Events” to generate the required Windows Security Event Logs (event ID 4702) as described in the setup instructions.
• Deploy the Sigma rule provided below to your SIEM to detect unusual scheduled task updates.
• Investigate any alerts generated by this rule to determine if the scheduled task modification is legitimate or malicious.
• Review the references provided to understand the underlying event IDs and attacker techniques related to scheduled tasks.

Attack Chain

1. An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).
2. The attacker escalates privileges to gain administrative access, allowing them to modify the registry.
3. The attacker directly modifies the HKLM\SYSTEM\ControlSet*\Services\*\ServiceDLL or HKLM\SYSTEM\ControlSet*\Services\*\ImagePath registry keys to point to a malicious DLL or executable.
4. The attacker’s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.
5. The compromised service starts automatically during system startup or manually when triggered by the attacker.
6. The malicious service executes arbitrary code, providing the attacker with persistent control over the system.
7. The attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence on the compromised system, maintaining access even after reboots or user logoffs. This can lead to long-term control over the system, enabling attackers to perform various malicious activities, including data theft, deployment of ransomware, or use of the system as a foothold for further attacks within the network. The severity is further amplified if critical services are targeted, potentially leading to system instability or denial of service.

Recommendation

• Enable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).
• Deploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).
• Tune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).
• Investigate any alerts generated by the Sigma rules, focusing on processes modifying the ServiceDLL or ImagePath registry values (Sigma rules).
• Review endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).

Attack Chain

1. An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
2. The attacker executes code on the system, potentially using a dropper or exploit.
3. The attacker identifies uncommon registry keys suitable for persistence.
4. The attacker modifies the registry key to point to a malicious executable or script. This may involve adding a new entry or modifying an existing one.
5. The system restarts, or the user logs in, triggering the execution of the malicious code through the modified registry key.
6. The malicious code executes with the privileges of the user or system, depending on the registry key modified.
7. The attacker achieves persistence, allowing them to maintain access to the system even after restarts.
8. The attacker performs malicious activities such as data exfiltration, lateral movement, or deploying ransomware.

Impact

A successful attack can lead to persistent access to the compromised system, allowing the attacker to maintain control and execute malicious activities. This can lead to data theft, system disruption, or further compromise of the network. The impact can range from a single workstation being compromised to a widespread enterprise-level breach, depending on the attacker’s objectives and the scope of the initial compromise.

Recommendation

• Deploy the “Uncommon Registry Persistence Change” Sigma rule to your SIEM to detect modifications to uncommon registry persistence keys and tune for your environment.
• Enable Sysmon registry event logging to ensure the visibility required for the Sigma rule to function effectively (see references).
• Review and tune the filter conditions in the Sigma rule to reduce false positives, specifically excluding legitimate software installations, system maintenance processes, and administrative scripts.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the registry modification and correlating it with other suspicious activities.
• Block execution of known malicious executables and scripts identified during the investigation to prevent further compromise.

Attack Chain

1. An internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.
2. The Azure Active Directory service checks the inviter’s permissions against the organization’s guest invitation policies.
3. The system determines the user lacks the necessary permissions to invite guest users.
4. Azure Audit Logs record the “Invite external user” event with a “failure” status.
5. The failed invitation attempt is blocked, preventing the external user from gaining access.
6. The attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.
7. If successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.

Impact

A successful privilege escalation could grant unauthorized access to sensitive data and resources within the Azure environment. While this specific detection focuses on failed attempts, repeated failures may indicate a concerted effort to bypass security controls. If successful, unauthorized guest users could be used for lateral movement, data exfiltration, or other malicious activities. The number of affected resources depends on the permissions granted to the guest user if the invitation had been successful.

Recommendation

• Deploy the Sigma rule “Guest User Invited By Non Approved Inviters” to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.
• Review and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.
• Monitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).

Attack Chain

1. Initial access is gained through phishing, exploitation of a vulnerability, or other means.
2. The attacker uploads or creates a malicious executable or script (e.g., PowerShell script) in a suspicious directory such as C:\Windows\Fonts\.
3. The attacker uses a dropper or loader to execute the malicious file. This can be achieved through various methods, including command-line execution or scheduled tasks.
4. The malicious process begins execution from the unusual file path.
5. The process performs malicious activities, such as downloading additional payloads, establishing command and control (C2) communication, or conducting reconnaissance.
6. The attacker leverages the compromised process to escalate privileges or move laterally within the network.
7. Data exfiltration or encryption may occur, depending on the attacker’s objectives.
8. The attacker attempts to maintain persistence by creating scheduled tasks or modifying registry keys to ensure the malicious process restarts upon system reboot.

Impact

Successful execution of malicious code from unusual file paths can lead to a variety of negative impacts, including system compromise, data theft, and ransomware infection. Organizations may experience data breaches, financial losses, and reputational damage. The references indicate this technique is associated with various malware families, including information stealers, remote access trojans (RATs), and ransomware, affecting numerous organizations across different sectors.

Recommendation

• Enable process creation logging (Event ID 4688 or Sysmon Event ID 1) to capture process execution events, including the process path, command line, and parent process information to enable the rules below.
• Deploy the Sigma rule “Suspicious Process Executing from Common Non-Executable Paths” to your SIEM to detect processes running from unusual file paths. Tune the rule to filter out any legitimate exceptions in your environment.
• Investigate any alerts generated by the Sigma rule, paying close attention to the process name, command line, and parent process.
• Implement application control policies to restrict the execution of unauthorized software in your environment.
• Monitor network traffic for suspicious outbound connections originating from processes running from unusual file paths.

Attack Chain

1. An attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).
2. The attacker uploads a malicious MOF file to the compromised system.
3. The attacker executes mofcomp.exe to compile the malicious MOF file.
4. mofcomp.exe processes the MOF file, creating new namespaces and classes or modifying existing ones in the WMI repository.
5. If the MOF file creates a WMI Event Subscription, it triggers the execution of a malicious script or binary when a specific event occurs.
6. The malicious script or binary executes, performing actions such as installing malware, creating backdoors, or exfiltrating data.
7. The attacker maintains persistence through the WMI Event Subscription, ensuring continued access even after system reboots.

Impact

Successful exploitation via malicious MOF files can lead to persistent access, code execution, and system compromise. Attackers can use this technique to install malware, create backdoors, or steal sensitive data. The rule aims to detect early stages of such attacks, preventing significant damage. By establishing persistence, attackers can maintain long-term control over the compromised system, evading traditional detection methods.

Recommendation

• Deploy the provided Sigma rules to your SIEM to detect suspicious mofcomp.exe activity and tune for your environment.
• Enable process creation logging and command-line auditing on Windows systems to capture necessary events for the provided Sigma rules.
• Investigate any alerts generated by the Sigma rules, focusing on unusual MOF file paths, parent processes, and user accounts.
• Review and monitor WMI namespaces and classes for unauthorized modifications or additions following any detected suspicious mofcomp.exe activity.

Attack Chain

1. An attacker gains initial access to a Windows system through an exploit or compromised credentials (not detailed in source).
2. The attacker escalates privileges to gain administrative rights on the system.
3. The attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages to include a path to a malicious DLL.
4. Alternatively, the attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages to include a path to a malicious DLL.
5. The attacker triggers a system reboot, or restarts the LSASS process, causing the malicious SSP DLL to be loaded.
6. The malicious DLL intercepts authentication credentials and exfiltrates them or performs other malicious actions.
7. The attacker maintains persistent access to the system, even after reboots.

Impact

Successful exploitation allows attackers to achieve persistence and potentially compromise sensitive credentials handled by LSASS. This can lead to lateral movement within the network, data exfiltration, and further system compromise. The impact is significant as it bypasses standard security measures and provides a persistent foothold for malicious activities.

Recommendation

• Deploy the Sigma rule “Suspicious SSP Registry Modification” to your SIEM to detect unauthorized modifications to SSP registry keys.
• Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
• Continuously monitor for unexpected processes writing to the HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages and HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages registry keys.
• Review and whitelist legitimate software installers that frequently modify these registry entries to reduce false positives as mentioned in the brief.
• Ensure access controls and permissions are strictly enforced to limit unauthorized modification of critical registry paths related to Security Support Providers.

Attack Chain

1. User opens a malicious Microsoft Office document (e.g., Word, Excel).
2. The document executes embedded macro code or exploits a vulnerability.
3. The macro or exploit leverages the Component Object Model (COM).
4. The Office application (e.g., WINWORD.EXE) loads the taskschd.dll library, providing access to the Task Scheduler service.
5. The COM interface is used to programmatically create a new scheduled task.
6. The scheduled task is configured to execute a malicious payload at a later time or on a recurring basis.
7. The malicious payload could be a script, executable, or command-line instruction.
8. Upon execution, the payload achieves the attacker’s objective, such as establishing persistence, downloading additional malware, or compromising the system.

Impact

A successful attack leveraging this technique can allow adversaries to maintain persistent access to a compromised system. This can lead to long-term data exfiltration, lateral movement within the network, and deployment of ransomware. The low severity score assigned to the original rule may underestimate the potential impact, as persistence is a critical component of many advanced attacks. Affected systems may require extensive remediation to remove all traces of the malicious activity.

Recommendation

• Deploy the Sigma rule “Office Application Loading Task Scheduler DLL” to your SIEM and tune for your environment to detect this specific activity.
• Enable Sysmon Event ID 7 (Image Loaded) logging on Windows endpoints to provide visibility into DLL loading events, which is a prerequisite for the Sigma rule.
• Investigate any alerts generated by the Sigma rule, focusing on the specific scheduled tasks that are created and the payloads they execute.
• Monitor for scheduled task creation events (Event ID 4698) and deletion events (Event ID 4699) in the Windows Event Logs, as referenced in the rule’s investigation guide.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.
2. The attacker attempts to enumerate existing EC2 instances and associated key pairs.
3. The attacker uses the CreateKeyPair API call to generate a new SSH key pair within the AWS account. The request originates from a network with an autonomous system organization not attributed to common cloud providers.
4. The attacker stores the private key material for later use in accessing EC2 instances.
5. The attacker may then use the new key pair to launch new EC2 instances or import the key to existing instances. This can be done through RunInstances or ImportKeyPair operations.
6. The attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.
7. Once inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.

Impact

Successful exploitation can lead to unauthorized access to EC2 instances, potentially compromising sensitive data and disrupting services. A compromised AWS account can allow the attacker to steal data, establish persistence, and move laterally within the cloud environment. The lack of expected cloud provider ASN for the source IP of the CreateKeyPair event raises the risk profile.

Recommendation

• Deploy the Sigma rule “AWS EC2 CreateKeyPair from Non-Cloud AS Organization” to your SIEM and tune the source.as.organization.name exclusions based on your environment.
• Review AWS CloudTrail logs for any CreateKeyPair events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.
• Implement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.
• Monitor for RunInstances or ImportKeyPair events using the newly created key names as identified from aws.cloudtrail.request_parameters / response_elements.
• Enable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.