{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/persistence/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","SentinelOne Cloud Funnel","Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SentinelOne","Crowdstrike","Elastic"],"content_html":"\u003cp\u003eThis detection identifies the modification of Discretionary Access Control Lists (DACLs) for Windows services using the \u003ccode\u003esc.exe\u003c/code\u003e utility. Attackers can leverage this technique to deny access to a service, making it unmanageable or hiding it from system administrators and users. The detection rule focuses on identifying instances where \u003ccode\u003esc.exe\u003c/code\u003e is used with the \u003ccode\u003esdset\u003c/code\u003e argument, specifically targeting the denial of access for key user groups such as IU, SU, BA, SY, and WD. This activity is indicative of a defense evasion attempt aimed at hindering security tools or preventing remediation. The rule is designed for data generated by Elastic Defend, but also supports integrations with third-party data sources like CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel, offering broad coverage for detecting this malicious behavior across diverse environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system through various means (e.g., compromised credentials, phishing).\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to gain necessary permissions to modify service configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003esc.exe\u003c/code\u003e with the \u003ccode\u003esdset\u003c/code\u003e command to modify the DACL of a targeted service.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esdset\u003c/code\u003e command arguments specify the new security descriptor, denying access to specific user groups (e.g., IU, SU, BA, SY, WD).\u003c/li\u003e\n\u003cli\u003eThe service becomes inaccessible to the targeted user groups, potentially disrupting legitimate operations or security tools.\u003c/li\u003e\n\u003cli\u003eThe attacker may repeat this process for multiple services to further impair system functionality or evade detection.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the disabled or hidden services to maintain persistence or carry out other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eService DACL Modification via sc.exe\u003c/code\u003e to your SIEM to detect this specific behavior.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to provide the necessary data for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where \u003ccode\u003esc.exe\u003c/code\u003e is used with the \u003ccode\u003esdset\u003c/code\u003e argument and access denial flags, focusing on the targeted user groups (IU, SU, BA, SY, WD).\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitor for unauthorized attempts to modify service configurations.\u003c/li\u003e\n\u003cli\u003eRegularly audit service permissions to identify and remediate any unauthorized changes.\u003c/li\u003e\n\u003cli\u003eReview 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-07-service-dacl-modification/","summary":"Detection of service DACL modifications via `sc.exe` using the `sdset` command, potentially leading to defense evasion by denying service access to legitimate users or system accounts.","title":"Service DACL Modification via sc.exe","url":"https://feed.craftedsignal.io/briefs/2024-07-service-dacl-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["medium"],"_cs_tags":["credential-access","persistence","active-directory","dcsync"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies modifications to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute within Active Directory (AD) objects that grant DCSync-related permissions to a user or computer account. This technique allows attackers to create a persistent backdoor, enabling them to re-obtain access to user and computer account hashes. The modification involves assigning specific GUIDs that represent replication rights (\u003ccode\u003e1131f6ad-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e1131f6aa-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e89e95b76-444d-4c62-991a-0facbeda640c\u003c/code\u003e) to an account\u0026rsquo;s security descriptor. This allows the attacker to then use DCSync to retrieve credentials from the domain, effectively bypassing normal authentication mechanisms.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an account with sufficient privileges to modify Active Directory objects (e.g., Domain Admin).\u003c/li\u003e\n\u003cli\u003eThe attacker uses AD management tools (PowerShell, ADSI Edit, etc.) to target a specific user or computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute of the targeted account.\u003c/li\u003e\n\u003cli\u003eThe attacker grants replication rights to the targeted account by adding specific Access Control Entries (ACEs) containing the GUIDs \u003ccode\u003e1131f6ad-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e1131f6aa-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, and \u003ccode\u003e89e95b76-444d-4c62-991a-0facbeda640c\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the DCSync technique, impersonating a domain controller, to request password hashes.\u003c/li\u003e\n\u003cli\u003eThe Active Directory server, believing the request is legitimate due to the granted replication rights, provides the attacker with the requested credential information.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains password hashes for domain users and computers.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained credentials for lateral movement, privilege escalation, or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Directory Service Changes to generate the necessary event logs for detection (\u003ca href=\"https://ela.st/audit-directory-service-changes)\"\u003ehttps://ela.st/audit-directory-service-changes)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to detect unauthorized modifications to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute. Tune the rule to exclude legitimate administrative accounts or scripts that may perform authorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Windows Security Event Logs (event code 5136) for changes to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute and investigate any unexpected modifications, focusing on the presence of DCSync-related GUIDs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Active Directory permissions, focusing on accounts with replication rights, to ensure they are legitimate and necessary.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2026-05-dcsync-backdoor/","summary":"Attackers can modify Active Directory object security descriptors to grant DCSync rights to unauthorized accounts, creating a backdoor to extract credential data.","title":"Potential Active Directory Replication Account Backdoor","url":"https://feed.craftedsignal.io/briefs/2026-05-dcsync-backdoor/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike FDR"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","lateral-movement","persistence","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThe LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled (set to 1), allows remote connections from local members of the Administrators group to be granted full high-integrity tokens during negotiation. This bypasses User Account Control (UAC) restrictions, allowing for elevated privileges remotely. Attackers may modify this registry setting to facilitate lateral movement within a network. This rule detects modifications to this specific registry setting, alerting on potential unauthorized changes that could lead to defense evasion and privilege escalation. The modification of this policy has been observed being leveraged in conjunction with pass-the-hash attacks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a system through an exploit, such as phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains local administrator credentials on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\LocalAccountTokenFilterPolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages a \u0026ldquo;pass the hash\u0026rdquo; attack (T1550.002) using the compromised local administrator credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally to other systems within the network using the \u0026ldquo;pass the hash\u0026rdquo; technique and the modified LocalAccountTokenFilterPolicy.\u003c/li\u003e\n\u003cli\u003eDue to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses UAC on the remote system, gaining elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities on the remote system, such as data exfiltration or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eLocal Account TokenFilter Policy Enabled\u003c/code\u003e to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture modifications to the registry, which is required for the \u003ccode\u003eLocal Account TokenFilter Policy Enabled\u003c/code\u003e Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for changes to the \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\LocalAccountTokenFilterPolicy\u003c/code\u003e path, specifically looking for changes to the value data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-01-02-local-account-token-filter-policy-disabled/","summary":"Adversaries may modify the LocalAccountTokenFilterPolicy registry key to bypass User Account Control (UAC) and gain elevated privileges remotely by granting high-integrity tokens to remote connections from local administrators, facilitating lateral movement and defense evasion.","title":"Local Account TokenFilter Policy Modification for Defense Evasion and Lateral Movement","url":"https://feed.craftedsignal.io/briefs/2024-01-02-local-account-token-filter-policy-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Endpoint Security"],"_cs_severities":["high"],"_cs_tags":["genai","credential-access","persistence","collection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eAttackers are increasingly leveraging GenAI agents to automate the discovery and exfiltration of sensitive information, including credentials, API keys, and tokens stored within files on compromised systems. The observed activity involves GenAI tools accessing critical files such as cloud credentials, SSH keys, browser password databases, and shell configuration files. Successful exploitation allows attackers to harvest credentials, gain unauthorized access to systems, and establish persistence mechanisms for continued access. The GenAI tools mentioned include ollama, textgen, lmstudio, claude, cursor, copilot, codex, jan, gpt4all, gemini-cli, genaiscript, grok, qwen, koboldcpp, llama-server, windsurf, zed, opencode, and goose. This activity highlights the emerging threat landscape of AI-assisted attacks and the need for robust detection and mitigation strategies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a system through an unrelated vulnerability or social engineering.\u003c/li\u003e\n\u003cli\u003eInstallation or execution of a GenAI tool (e.g., ollama, lmstudio) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool is configured or instructed to scan the file system for sensitive files.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool accesses files containing credentials, such as \u003ccode\u003e.aws/credentials\u003c/code\u003e, browser password databases (\u003ccode\u003eLogin Data\u003c/code\u003e, \u003ccode\u003ekey3.db\u003c/code\u003e), or SSH keys (\u003ccode\u003e.ssh/id_*\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe GenAI tool exfiltrates the harvested credentials and API keys to a remote server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to cloud resources, internal systems, or other sensitive accounts.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool attempts to modify shell configuration files (e.g., \u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e) to establish persistence.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user login, the modified shell configuration executes malicious commands, granting the attacker persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GenAI Process Accessing Sensitive Files\u0026rdquo; to your SIEM to detect GenAI tools accessing sensitive files on endpoints.\u003c/li\u003e\n\u003cli\u003eEnable file access monitoring on systems where GenAI tools are used to capture access events for analysis.\u003c/li\u003e\n\u003cli\u003eReview and restrict the use of GenAI tools within the environment, especially concerning access to sensitive file paths.\u003c/li\u003e\n\u003cli\u003eMonitor for modifications to shell configuration files (e.g., \u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e, \u003ccode\u003e.profile\u003c/code\u003e) as an indicator of persistence attempts.\u003c/li\u003e\n\u003cli\u003eImplement regular credential rotation policies to minimize the impact of stolen credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T22:46:51Z","date_published":"2026-05-01T22:46:51Z","id":"/briefs/2024-12-15-genai-sensitive-file-access/","summary":"This threat brief details the detection of GenAI tools accessing sensitive files containing credentials, SSH keys, browser data, and shell configurations, indicating potential credential harvesting and persistence attempts by attackers leveraging GenAI agents.","title":"GenAI Tools Accessing Sensitive Files for Credential Access and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-12-15-genai-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS Lambda"],"_cs_severities":["high"],"_cs_tags":["aws","iam","lambda","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat focuses on the abuse of AWS Lambda execution roles to perform sensitive IAM operations. Lambda functions, often running with over-permissioned roles, can be exploited by adversaries to escalate privileges and establish persistence within an AWS environment. An attacker gaining control of a Lambda function can leverage its execution role to make IAM API calls that would normally require elevated permissions. This includes creating new IAM users or roles, attaching policies to existing IAM entities, and modifying EC2 instance profiles. The scope of this threat includes any AWS environment utilizing Lambda functions with IAM permissions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the Lambda function\u0026rsquo;s execution role, which has excessive IAM permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker executes IAM API calls, such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eCreateRole\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e, to create new IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, \u003ccode\u003ePutUserPolicy\u003c/code\u003e, \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, or \u003ccode\u003ePutRolePolicy\u003c/code\u003e to grant elevated permissions to the newly created or existing IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies instance profiles using \u003ccode\u003eCreateInstanceProfile\u003c/code\u003e and \u003ccode\u003eAddRoleToInstanceProfile\u003c/code\u003e to prepare EC2 instances for lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via \u003ccode\u003ests:AssumeRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating rogue IAM users, roles, or access keys.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Sensitive Operations via Lambda Execution Role\u0026rdquo; to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e to identify the Lambda function and associated deployment path responsible for the IAM API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e for targets such as \u003ccode\u003euserName\u003c/code\u003e, \u003ccode\u003egroupName\u003c/code\u003e, \u003ccode\u003eroleName\u003c/code\u003e, \u003ccode\u003epolicyArn\u003c/code\u003e, or \u003ccode\u003einstanceProfileName\u003c/code\u003e to understand the scope of the IAM operations.\u003c/li\u003e\n\u003cli\u003eRevoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eRemediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-09-aws-lambda-iam-privilege-escalation/","summary":"Detection of IAM API calls that create or empower IAM users and roles, attach policies, or configure instance profiles when the caller is an assumed role session associated with AWS Lambda, potentially indicating privilege escalation or persistence.","title":"AWS IAM Privilege Operations via Lambda Execution Role","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-lambda-iam-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Google Workspace"],"_cs_severities":["medium"],"_cs_tags":["googleworkspace","intrusion","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis alert focuses on identifying potentially malicious login attempts within Google Workspace environments. The detection is based on Google\u0026rsquo;s own flagging of a login as a potential \u0026ldquo;gov_attack_warning,\u0026rdquo; suggesting that Google\u0026rsquo;s threat intelligence attributes the activity to a government-backed actor. While specific targeting information is unavailable, this alert highlights a critical area for investigation within organizations utilizing Google Workspace, especially those handling sensitive data or operating in sectors of interest to nation-state actors. This detection provides an early warning of potential compromise or data exfiltration attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker attempts to log into a Google Workspace account using compromised or brute-forced credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLogin Attempt:\u003c/strong\u003e The login attempt triggers a \u0026ldquo;gov_attack_warning\u0026rdquo; within Google Workspace, indicating a potential government-backed threat actor.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Potential):\u003c/strong\u003e If the compromised account has elevated privileges, the attacker may attempt to escalate privileges within the Google Workspace environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion (Potential):\u003c/strong\u003e The attacker may attempt to disable security features or modify audit logs to evade detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Potential):\u003c/strong\u003e The attacker may establish persistent access through methods such as creating rogue apps or modifying account settings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access:\u003c/strong\u003e The attacker gains access to sensitive data stored within Google Workspace, such as documents, emails, and files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExfiltration (Potential):\u003c/strong\u003e The attacker exfiltrates the stolen data to an external location.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The organization suffers a data breach, reputational damage, and potential financial losses.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s access and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u0026ldquo;gov_attack_warning\u0026rdquo; events in Google Workspace logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts promptly, focusing on the affected user account and associated activity.\u003c/li\u003e\n\u003cli\u003eReview the Google Workspace audit logs for any suspicious activity leading up to the \u0026ldquo;gov_attack_warning\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Google Workspace accounts, especially those with elevated privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Google Workspace activity logs for suspicious patterns, such as unusual login locations, failed login attempts, and changes to account settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-28T00:48:14Z","date_published":"2026-04-28T00:48:14Z","id":"/briefs/2024-01-23-gworkspace-govattack/","summary":"A Google Workspace login attempt flagged as a potential attack by a government-backed threat actor, indicating potential privilege escalation, defense evasion, persistence, initial access, or impact.","title":"Google Workspace Login Attempt with Government Attack Warning","url":"https://feed.craftedsignal.io/briefs/2024-01-23-gworkspace-govattack/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege-escalation","linux","sudoers"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe sudoers.d directory on Linux systems is designed to allow administrators to manage sudo privileges by adding individual files rather than modifying the main /etc/sudoers file. An attacker who gains initial access to a system can exploit this by creating or modifying files within this directory to grant themselves or other malicious actors elevated privileges. This can be done to ensure persistent access, even if other initial access methods are detected and remediated. The modification of…\u003c/p\u003e\n","date_modified":"2026-04-27T23:12:30Z","date_published":"2026-04-27T23:12:30Z","id":"/briefs/2026-04-sudoers-persistence/","summary":"Attackers can achieve persistence and privilege escalation on Linux systems by creating or modifying files in the /etc/sudoers.d/ directory to grant unauthorized users or groups sudo privileges.","title":"Linux Persistence via Sudoers.d File Manipulation","url":"https://feed.craftedsignal.io/briefs/2026-04-sudoers-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","genai","file-access","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers are increasingly exploiting GenAI tools to automate the discovery and exfiltration of sensitive information from compromised systems. This involves using GenAI agents to systematically scan file systems for credentials, API keys, tokens, and other secrets. Access to credential stores (.aws/credentials, .ssh/id_*) indicates credential harvesting, while modifications to shell configuration files (.bashrc, .zshrc) point to persistence attempts.  The observed activity leverages legitimate GenAI tool functionality, making it difficult to distinguish between benign use and malicious intent.  This technique has become more prevalent since late 2025, with attackers refining methods to instruct GenAI agents to specifically target and exfiltrate sensitive files. Defenders must monitor for unusual file access patterns by GenAI processes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system via phishing or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eAttacker installs or deploys a GenAI tool (e.g., LM Studio, Claude, Copilot) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the GenAI tool to scan the file system for specific file names and patterns associated with sensitive data (credentials, keys, cookies).\u003c/li\u003e\n\u003cli\u003eThe GenAI tool accesses files such as \u003ccode\u003e.aws/credentials\u003c/code\u003e, \u003ccode\u003e.ssh/id_rsa\u003c/code\u003e, browser login databases (e.g., \u003ccode\u003eLogin Data\u003c/code\u003e, \u003ccode\u003elogins.json\u003c/code\u003e, \u003ccode\u003eCookies\u003c/code\u003e), and other credential stores.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool may modify shell configuration files (\u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e) to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool stages the collected data for exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the harvested credentials and data to an external server.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to other systems or cloud resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGenAI Process Accessing Sensitive Files\u003c/code\u003e to your SIEM to detect GenAI tools accessing sensitive files. Tune for your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eMonitor file access events, specifically looking for GenAI processes (ollama, lmstudio, claude) accessing files with names like \u003ccode\u003ecredentials\u003c/code\u003e, \u003ccode\u003eid_rsa\u003c/code\u003e, \u003ccode\u003elogins.json\u003c/code\u003e, and \u003ccode\u003e.bashrc\u003c/code\u003e, as outlined in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and monitoring for sensitive directories like \u003ccode\u003e.aws\u003c/code\u003e, \u003ccode\u003e.ssh\u003c/code\u003e, and browser profile directories.\u003c/li\u003e\n\u003cli\u003eRegularly audit and rotate credentials, API keys, and tokens, especially those stored in files.\u003c/li\u003e\n\u003cli\u003eEducate developers and users about the risks of using GenAI tools to handle sensitive data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T16:34:10Z","date_published":"2026-04-22T16:34:10Z","id":"/briefs/2024-01-genai-sensitive-file-access/","summary":"This brief outlines the threat of attackers leveraging GenAI tools to access sensitive files containing credentials, SSH keys, browser data, and shell configurations for credential access and persistence.","title":"GenAI Tool Access to Sensitive Files for Credential Harvesting and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-genai-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["state-sponsored","apt","persistence","vulnerability-exploitation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eIn 2025, state-sponsored threat actors from China, Russia, North Korea, and Iran exhibited distinct motivations, ranging from espionage and disruption to financial gain and geopolitical influence. Despite these varying objectives, these actors employed similar tactics, techniques, and procedures (TTPs), particularly regarding initial access and persistence. A common thread was the exploitation of both newly disclosed (e.g., ToolShell by China) and long-standing vulnerabilities in networking devices and widely used software. Identity-based attacks, including social engineering and the use of stolen credentials, were also prominent. North Korea notably stole $1.5 billion in cryptocurrency and generated billions through fraudulent IT work using AI-generated profiles. Iranian actors combined disruptive hacktivism with advanced persistent threat (APT) activity, such as the ShroudedSnooper group targeting telecommunications for long-term access. The focus across these actors was on establishing a persistent presence within compromised networks, often remaining undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerability Exploitation (Initial Access):\u003c/strong\u003e Actors exploit vulnerabilities in networking devices and widely used software, leveraging both newly disclosed and unpatched flaws.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSocial Engineering (Initial Access):\u003c/strong\u003e North Korean actors use fake recruiter personas via campaigns like Contagious Interview to trick targets into executing code or handing over credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Harvesting (Privilege Escalation/Persistence):\u003c/strong\u003e After initial access, actors harvest credentials to gain further access within the network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWeb Shell Deployment (Persistence):\u003c/strong\u003e Chinese actors deploy web shells for persistent access to compromised systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCustom Backdoor Installation (Persistence):\u003c/strong\u003e Backdoors, including compact custom backdoors like those used by ShroudedSnooper, are deployed to maintain long-term access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTunneling (Command \u0026amp; Control):\u003c/strong\u003e Actors use tunneling tools to maintain covert communication channels with compromised systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration (Exfiltration):\u003c/strong\u003e Actors exfiltrate sensitive data, including espionage-related information or financial data such as cryptocurrency.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisruption/Espionage (Impact):\u003c/strong\u003e Depending on the actor and objective, the final stage involves disruptive activities like DDoS attacks or long-term espionage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePrioritize patching of both newly disclosed and long-standing vulnerabilities in networking devices and software to mitigate initial access (Reference: Overview, Attack Chain Step 1).\u003c/li\u003e\n\u003cli\u003eImplement 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 \u0026amp; 3).\u003c/li\u003e\n\u003cli\u003eIncrease 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, \u0026amp; 6).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules below to detect suspicious web shell activity and backdoor installations (Reference: Rules).\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for unusual patterns and connections indicative of tunneling or data exfiltration (Reference: Attack Chain Steps 6 \u0026amp; 7).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T13:51:01Z","date_published":"2026-04-14T13:51:01Z","id":"/briefs/2026-04-state-sponsored-access/","summary":"In 2025, state-sponsored actors from China, Russia, North Korea, and Iran leveraged vulnerabilities and identity compromise for initial access, focusing on persistence for long-term espionage or disruption.","title":"State-Sponsored Actors Leveraging Vulnerabilities and Identity for Persistent Access (2025)","url":"https://feed.craftedsignal.io/briefs/2026-04-state-sponsored-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["registry-modification","persistence","defense-evasion","scripting-engine"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis brief covers suspicious registry modifications made by scripting engine processes like WScript, CScript, and MSHTA. These processes are often abused by attackers to modify the registry without using standard tools like regedit.exe or reg.exe, potentially for evasion and persistence. Legitimate use of these scripting engines to modify the registry is uncommon, making this behavior a good indicator of potential malicious activity. Defenders should monitor for these processes interacting with sensitive registry keys. This activity was observed as of 2025 and continues to be a relevant technique for persistence and defense evasion in 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system via an exploit or social engineering.\u003c/li\u003e\n\u003cli\u003eThe attacker uses MSHTA.exe to execute malicious HTML Application code.\u003c/li\u003e\n\u003cli\u003eMSHTA.exe is used to launch a PowerShell script.\u003c/li\u003e\n\u003cli\u003eThe PowerShell script uses the Registry module to add a new registry key.\u003c/li\u003e\n\u003cli\u003eThe registry key is configured to execute a payload upon system startup.\u003c/li\u003e\n\u003cli\u003eThe attacker uses wscript.exe or cscript.exe to execute VBScript or JScript.\u003c/li\u003e\n\u003cli\u003eThe script modifies registry values to disable security features.\u003c/li\u003e\n\u003cli\u003eThe compromised system restarts, executing the payload defined in the registry, granting the attacker persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives and the compromised system\u0026rsquo;s role within the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; to your SIEM to detect this specific activity, and tune for your environment (rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of wscript.exe, cscript.exe or mshta.exe modifying registry keys outside of known-good paths (rules).\u003c/li\u003e\n\u003cli\u003eMonitor registry events for unexpected modifications by scripting engines, focusing on persistence-related keys (rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T12:50:16Z","date_published":"2026-04-14T12:50:16Z","id":"/briefs/2026-04-susp-reg-mod/","summary":"Scripting engines such as WScript, CScript, and MSHTA are being used to make registry modifications, potentially for persistence or defense evasion.","title":"Suspicious Registry Modifications by Scripting Engines","url":"https://feed.craftedsignal.io/briefs/2026-04-susp-reg-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","entra_id","persistence","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies potentially malicious activity within Microsoft Entra ID (Azure AD) involving the Microsoft Authentication Broker (MAB). Specifically, it focuses on OAuth 2.0 token requests where MAB (application ID 29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (DRS) (resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user. The presence of the \u003ccode\u003eadrs_access\u003c/code\u003e scope within the authentication processing details signals an attempt to interact with the ADRS (Azure Device Registration Service), an action not typically associated with standard user sign-ins. This behavior could indicate an attacker attempting to abuse device registration mechanisms to achieve persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. The Volexity report from April 2025 highlights similar OAuth workflow targeting.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises user credentials through phishing or other means.\u003c/li\u003e\n\u003cli\u003eAttacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.\u003c/li\u003e\n\u003cli\u003eThe Microsoft Authentication Broker is used to request an access token.\u003c/li\u003e\n\u003cli\u003eThe request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.\u003c/li\u003e\n\u003cli\u003eThe OAuth scope includes \u003ccode\u003eadrs_access\u003c/code\u003e, indicating an attempt to access ADRS functionalities.\u003c/li\u003e\n\u003cli\u003eThe request is made using a refresh token, suggesting an attempt to establish persistent access.\u003c/li\u003e\n\u003cli\u003eSuccessful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the PRT or device registration to maintain unauthorized access to resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could allow an attacker to maintain persistent access to an organization\u0026rsquo;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\u0026rsquo;s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Entra ID ADRS Token Request by Microsoft Authentication Broker\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.\u003c/li\u003e\n\u003cli\u003eReview Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eMonitor Entra ID audit logs for device registrations or changes to user\u0026rsquo;s device registration status as suggested in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eCorrelate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule\u0026rsquo;s triage.\u003c/li\u003e\n\u003cli\u003eConsider 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T17:57:29Z","date_published":"2026-04-10T17:57:29Z","id":"/briefs/2026-06-adrs-token-request/","summary":"Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker requests access to the Device Registration Service on behalf of a user principal, potentially indicating an attempt to abuse device registration for unauthorized persistence.","title":"Entra ID ADRS Token Request by Microsoft Authentication Broker","url":"https://feed.craftedsignal.io/briefs/2026-06-adrs-token-request/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule detects the creation of a console login profile for the AWS account root user, a highly privileged account. While \u003ccode\u003eCreateLoginProfile\u003c/code\u003e is normally applied to IAM users, when executed from a temporary root session (e.g., via \u003ccode\u003eAssumeRoot\u003c/code\u003e) without specifying a \u003ccode\u003euserName\u003c/code\u003e, the profile is created for the root principal. This activity is especially concerning because it provides persistent access. An attacker gaining temporary root access via STS or credential compromise might exploit this to set a root password. The attacker can then use this new password to log in through the console. This method circumvents traditional access key rotation or disabling and can be employed even after the initial vulnerability is patched. This activity started being tracked on 2024-12-02, defenders need to be aware of this persistence mechanism and promptly investigate any such incidents.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eAssumeRoot\u003c/code\u003e API call to assume the privileges of the root user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call without specifying a \u003ccode\u003euserName\u003c/code\u003e. This action creates a console login profile directly for the root account instead of an IAM user. The \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e will not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the root account using the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API. \u003ccode\u003epasswordResetRequired\u003c/code\u003e might be set to \u003ccode\u003etrue\u003c/code\u003e or omitted, with omission potentially indicating an attacker-controlled password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a \u003ccode\u003eConsoleLogin\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the root account\u0026rsquo;s privileges to create or modify resources, escalate privileges, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.\u003c/li\u003e\n\u003cli\u003eThe attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Login Profile Added for Root\u0026rdquo; to detect unauthorized creation of login profiles for the root account and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events where \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e is \u003ccode\u003eRoot\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e does not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.\u003c/li\u003e\n\u003cli\u003eReview IAM policies for least-privilege adherence, focusing on \u003ccode\u003eiam:CreateLoginProfile\u003c/code\u003e, \u003ccode\u003eiam:UpdateLoginProfile\u003c/code\u003e, and \u003ccode\u003eiam:CreateAccessKey\u003c/code\u003e permissions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-12-aws-root-login-profile/","summary":"An adversary with temporary root access in AWS may create a login profile for the root account to establish persistent console access, even if the original access keys are rotated or disabled.","title":"AWS IAM Login Profile Added for Root","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-root-login-profile/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["persistence","macos","python"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief highlights the malicious use of Python to establish persistence on macOS systems. Attackers can achieve Python code execution through various means, including malicious scripts, compromised dependencies, or even model file deserialization vulnerabilities (such as pickle or PyTorch \u003ccode\u003e__reduce__\u003c/code\u003e exploits). Once code execution is achieved, attackers can drop plist files into LaunchAgent or LaunchDaemon directories, ensuring their payload survives reboots and user logouts. This persistence mechanism allows the attacker to maintain access and control over the compromised host. Legitimate Python processes typically do not create persistence mechanisms in this manner, making the first occurrence of such activity a strong indicator of compromise.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the macOS system through methods such as exploiting vulnerabilities, social engineering, or phishing.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003epickle.load\u003c/code\u003e or \u003ccode\u003etorch.load\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Python process writes the crafted plist file to either the \u003ccode\u003e/Library/LaunchAgents/\u003c/code\u003e (for user-level persistence) or \u003ccode\u003e/Library/LaunchDaemons/\u003c/code\u003e (for system-level persistence) directory.\u003c/li\u003e\n\u003cli\u003eThe LaunchAgent or LaunchDaemon is automatically loaded by \u003ccode\u003elaunchd\u003c/code\u003e at login or boot, according to the configuration specified in the plist file.\u003c/li\u003e\n\u003cli\u003eThe program specified in the plist file is executed, giving the attacker persistent access to the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker can then use this persistent access to perform various malicious activities, such as data exfiltration, lateral movement, or deploying additional malware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s objectives and the system\u0026rsquo;s role within the network.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Python Launch Agent/Daemon Creation\u0026rdquo; to your SIEM to identify when a Python process creates a LaunchAgent or LaunchDaemon plist file.\u003c/li\u003e\n\u003cli\u003eEnable Elastic Defend endpoint logging to capture \u003ccode\u003eevent.action:\u0026quot;launch_daemon\u0026quot;\u003c/code\u003e events, which are necessary for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003ePrioritize 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.\u003c/li\u003e\n\u003cli\u003eImplement strict dependency management and vulnerability scanning for Python environments to prevent the use of compromised packages.\u003c/li\u003e\n\u003cli\u003eMonitor for processes loading model files (\u003ccode\u003etorch.load\u003c/code\u003e, \u003ccode\u003epickle.load\u003c/code\u003e) and investigate any suspicious activity to prevent exploitation of deserialization vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-08T21:12:54Z","date_published":"2026-04-08T21:12:54Z","id":"/briefs/2026-06-python-launch-agent-persistence/","summary":"This rule detects the initial creation or modification of a macOS LaunchAgent or LaunchDaemon plist file by a Python process, a common persistence technique employed by attackers using malicious scripts, compromised dependencies, or model file deserialization.","title":"First Time Python Process Creates macOS Launch Agent or Daemon","url":"https://feed.craftedsignal.io/briefs/2026-06-python-launch-agent-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["zip-slip","path-traversal","code-marketplace","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA Zip Slip vulnerability (CVE-2026-35454) exists in the Coder code-marketplace application, specifically in versions up to 2.4.1. The vulnerability stems from improper sanitization of zip entry names during VSIX file extraction, which allows an attacker to write files to arbitrary locations on the server. This flaw, discovered by Kandlaguduru Vamsi and detailed in GHSA-8x9r-hvwg-c55h, can be exploited by any authenticated user with upload privileges. Successful exploitation could lead to persistence via cron/init injection, SSH key injection, \u003ccode\u003eld.so.preload\u003c/code\u003e hijacking, or binary overwrite. The vulnerability was patched in version 2.4.2. Defenders should upgrade to the latest version of the code-marketplace application to prevent potential exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn authenticated user with upload privileges logs into the code-marketplace application.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious VSIX file containing zip entries with path traversal sequences (e.g., \u0026ldquo;../../../etc/cron.d/evil\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe attacker uploads the malicious VSIX file through the application\u0026rsquo;s extension upload functionality.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eExtractZip\u003c/code\u003e function processes the uploaded VSIX file without proper sanitization of zip entry names.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003efilepath.Join\u003c/code\u003e function constructs the output path using the unsanitized zip entry name and a base directory.\u003c/li\u003e\n\u003cli\u003ePath traversal sequences like \u003ccode\u003e..\u003c/code\u003e are resolved by \u003ccode\u003efilepath.Clean\u003c/code\u003e, but the resulting path is not checked against the intended base directory, allowing it to escape.\u003c/li\u003e\n\u003cli\u003eThe application writes the extracted file to an attacker-controlled location on the server\u0026rsquo;s file system.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the coder/code-marketplace application to version 2.4.2 or later to remediate CVE-2026-35454.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious File Creation in Sensitive Directories\u0026rdquo; to detect potential exploitation attempts based on file creation events.\u003c/li\u003e\n\u003cli\u003eEnable webserver logging and deploy the provided Sigma rule \u0026ldquo;Detect VSIX Uploads with Path Traversal\u0026rdquo; to identify suspicious VSIX uploads containing path traversal sequences based on request parameters.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-04T06:29:50Z","date_published":"2026-04-04T06:29:50Z","id":"/briefs/2026-06-code-marketplace-zip-slip/","summary":"A Zip Slip vulnerability in coder/code-marketplace allows authenticated users to upload malicious VSIX files containing path traversal entries, leading to arbitrary file writes outside the extension directory and potentially enabling persistence.","title":"Coder Code-Marketplace Zip Slip Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-06-code-marketplace-zip-slip/"},{"_cs_actors":["BRICKSTORM"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["vsphere","virtualization","brickstorm","persistence","lateral-movement"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eThe BRICKSTORM campaign targets VMware vSphere environments, with a focus on the vCenter Server Appliance (VCSA) and ESXi hypervisors. This campaign, building on previous BRICKSTORM research, highlights the increasing threats targeting virtualized infrastructure. By gaining persistence at the virtualization layer, attackers bypass traditional security measures, such as endpoint detection and response (EDR) agents, which are often ineffective in these environments. The attackers exploit weak security architectures, identity design flaws, lack of host-based configuration enforcement, and limited visibility within the virtualization layer. This allows them to maintain long-term persistence and gain administrative control over the entire vSphere environment, making the VCSA a prime target due to its centralized control. This activity is not due to vendor vulnerabilities but rather misconfigurations and security gaps. vSphere 7 reached End of Life (EoL) in October 2025, so organizations using this version are at increased risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to the vSphere environment, potentially through compromised credentials or vulnerabilities in externally facing services.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVCSA Compromise:\u003c/strong\u003e The attacker targets the vCenter Server Appliance (VCSA) to gain centralized control over the vSphere environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates privileges within the VCSA to gain root or administrative access to the underlying Photon Linux OS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by modifying system files or creating malicious services that survive reboots. This may involve writing scripts to \u003ccode\u003e/etc/rc.local.d\u003c/code\u003e or modifying startup files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses the compromised VCSA to move laterally to other ESXi hosts and virtual machines within the environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access:\u003c/strong\u003e The attacker accesses the underlying storage (VMDKs) of virtual machines, bypassing operating system permissions and traditional file system security, to exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eControl of ESXi Hosts:\u003c/strong\u003e The attacker resets root credentials on any managed ESXi host, providing full control of the hypervisor.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eHarden the vCenter Server Appliance (VCSA) by implementing the security configurations recommended in the Mandiant vCenter Hardening Script (reference: vCenter Hardening Script link in Overview).\u003c/li\u003e\n\u003cli\u003eImplement logging and monitoring for the Photon OS shell to detect unauthorized access and command execution (reference: Phase 4 in Content).\u003c/li\u003e\n\u003cli\u003eUpgrade to a supported version of vSphere to receive critical security patches (reference: vSphere 7 End of Life in Content).\u003c/li\u003e\n\u003cli\u003eEnable Secure Boot, strictly firewall management interfaces, and disable shell access on ESXi hosts and the VCSA (reference: Technical Hardening in Content).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect modifications to startup files for persistence on Photon OS (reference: Sigma rule: \u0026ldquo;Detect Startup File Modification in Photon OS\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T13:55:05Z","date_published":"2026-04-02T13:55:05Z","id":"/briefs/2026-04-brickstorm-vsphere/","summary":"The BRICKSTORM malware targets VMware vSphere environments, specifically vCenter Server Appliance (VCSA) and ESXi hypervisors, by exploiting weak security configurations to establish persistence at the virtualization layer, leading to administrative control and potential data exfiltration.","title":"BRICKSTORM Malware Targeting VMware vSphere Environments","url":"https://feed.craftedsignal.io/briefs/2026-04-brickstorm-vsphere/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["container","persistence","lateral-movement","privilege-escalation","ssh"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection focuses on identifying malicious actors who modify SSH authorized_keys files inside containers to gain unauthorized access. SSH authorized keys are used for public key authentication, and modification of these files allows attackers to maintain persistence or move laterally within a containerized environment. The rule specifically looks for file creation and modification events of authorized_keys files within Linux-based containers. Introduced as part of the Defend for Containers integration in Elastic Stack version 9.3.0, this detection is crucial because unauthorized SSH access can lead to significant compromise within cloud environments and containerized workloads. Defenders need to be aware of unexpected SSH key modifications as indicators of compromise inside containerized environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands within the container to locate the SSH authorized_keys file (typically located at \u003ccode\u003e/home/\u0026lt;user\u0026gt;/.ssh/authorized_keys\u003c/code\u003e or \u003ccode\u003e/root/.ssh/authorized_keys\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like \u003ccode\u003eecho \u0026quot;ssh-rsa AAAAB3Nz...\u0026quot; \u0026gt;\u0026gt; /root/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly added SSH key to authenticate and log into the container without needing a password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable \u003ccode\u003eElastic Defend for Containers\u003c/code\u003e integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule\u0026rsquo;s description (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.\u003c/li\u003e\n\u003cli\u003eCreate exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T12:00:00Z","date_published":"2026-04-02T12:00:00Z","id":"/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/","summary":"The rule detects the creation or modification of an authorized_keys file inside a container, a technique used by adversaries to maintain persistence on a victim host by adding their own public key(s) to enable unauthorized SSH access for lateral movement or privilege escalation.","title":"SSH Authorized Key File Modification Inside a Container","url":"https://feed.craftedsignal.io/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","defense-evasion","persistence","initial-access","active-directory"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on the modification of the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attribute within Active Directory via PowerShell scripts. This activity is flagged as potentially malicious because it could be indicative of an attempt to exploit the \u0026lsquo;BadSuccessor\u0026rsquo; privilege escalation vulnerability in Windows Server 2025. The vulnerability, as outlined in Akamai\u0026rsquo;s research, allows attackers to manipulate managed service account (dMSA) links to gain elevated privileges. The detection is based on identifying specific PowerShell script patterns that include \u003ccode\u003e.Put(\u0026quot;msDS-ManagedAccountPrecededByLink'\u003c/code\u003e and \u003ccode\u003eCN=\u003c/code\u003e, which are used to modify these critical AD attributes. Defenders should be aware that legitimate administrative tasks might also trigger this detection, so careful tuning and validation are necessary.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e 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).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker uses PowerShell to enumerate existing dMSAs and their associated \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attributes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAttribute Modification:\u003c/strong\u003e The attacker crafts a PowerShell script to modify the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attribute of a target dMSA. This involves using the \u003ccode\u003e.Put(\u0026quot;msDS-ManagedAccountPrecededByLink\u0026quot;\u003c/code\u003e command and specifying a new distinguished name (\u003ccode\u003eCN=\u003c/code\u003e) for the preceding account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker leverages the modified dMSA link to establish a persistent foothold in the environment by gaining control over the targeted dMSA.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e By manipulating the dMSA links, the attacker effectively inherits the permissions and privileges associated with the compromised dMSA, thereby escalating their own privileges.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker may attempt to evade detection by obfuscating the PowerShell script or using other techniques to hide their activity.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With elevated privileges, the attacker can move laterally within the network, accessing sensitive resources and systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of the \u0026lsquo;BadSuccessor\u0026rsquo; vulnerability through modification of the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy 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).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule to determine if the activity is legitimate or indicative of an attempted exploitation of the \u0026lsquo;BadSuccessor\u0026rsquo; vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitoring for systems and accounts with the ability to modify Active Directory attributes.\u003c/li\u003e\n\u003cli\u003eReview and harden Active Directory security configurations to prevent unauthorized modification of sensitive attributes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-30T10:27:13Z","date_published":"2026-03-30T10:27:13Z","id":"/briefs/2024-01-30-dmsa-link-mod/","summary":"Detection of PowerShell scripts modifying the msDS-ManagedAccountPrecededByLink attribute, potentially indicating exploitation of the BadSuccessor privilege escalation vulnerability in Windows Server 2025.","title":"Potential Abuse of msDS-ManagedAccountPrecededByLink for Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-30-dmsa-link-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["path-traversal","file-write","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe \u003ccode\u003e@mobilenext/mobile-mcp\u003c/code\u003e npm package, versions prior to 0.0.49, contains a critical path traversal vulnerability. This flaw stems from the \u003ccode\u003emobile_save_screenshot\u003c/code\u003e and \u003ccode\u003emobile_start_screen_recording\u003c/code\u003e tools which improperly handle user-supplied paths. Specifically, the \u003ccode\u003esaveTo\u003c/code\u003e parameter in \u003ccode\u003emobile_save_screenshot\u003c/code\u003e and the \u003ccode\u003eoutput\u003c/code\u003e parameter in \u003ccode\u003emobile_start_screen_recording\u003c/code\u003e are passed directly to filesystem write operations without adequate validation. This oversight enables a malicious actor to write arbitrary files to locations outside of the intended workspace. A successful exploit of this vulnerability allows for the potential overwriting of sensitive system files, enabling privilege escalation and persistence on the host system.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains control over the \u003ccode\u003esaveTo\u003c/code\u003e or \u003ccode\u003eoutput\u003c/code\u003e parameter of the vulnerable functions. This could be achieved through a malicious application, supply chain attack, or other means of code injection.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a path containing traversal sequences (e.g., \u003ccode\u003e../\u003c/code\u003e) designed to navigate outside of the intended save directory.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003emobile_save_screenshot\u003c/code\u003e or \u003ccode\u003emobile_start_screen_recording\u003c/code\u003e tool with the manipulated path as the \u003ccode\u003esaveTo\u003c/code\u003e or \u003ccode\u003eoutput\u003c/code\u003e parameter, respectively.\u003c/li\u003e\n\u003cli\u003eThe vulnerable function passes the attacker-controlled path to \u003ccode\u003efs.writeFileSync()\u003c/code\u003e without validation.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003efs.writeFileSync()\u003c/code\u003e writes the screenshot or screen recording data to the attacker-specified path.\u003c/li\u003e\n\u003cli\u003eIf the path leads to a sensitive system file (e.g., \u003ccode\u003e~/.bashrc\u003c/code\u003e, \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e), it is overwritten with the contents of the screenshot or screen recording.\u003c/li\u003e\n\u003cli\u003eThe attacker can overwrite configuration files or executables in order to achieve code execution.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence and/or elevated privileges on the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this path traversal vulnerability can have severe consequences. An attacker can overwrite critical system files, such as shell configuration files (\u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e), SSH authorized keys (\u003ccode\u003e.ssh/authorized_keys\u003c/code\u003e), 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 \u003ccode\u003e@mobilenext/mobile-mcp\u003c/code\u003e versions prior to 0.0.49 are vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to \u003ccode\u003e@mobilenext/mobile-mcp\u003c/code\u003e version 0.0.49 or later to remediate the vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement robust input validation for all file paths used in file system operations. Specifically, validate the \u003ccode\u003esaveTo\u003c/code\u003e and \u003ccode\u003eoutput\u003c/code\u003e parameters of the \u003ccode\u003emobile_save_screenshot\u003c/code\u003e and \u003ccode\u003emobile_start_screen_recording\u003c/code\u003e functions.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Mobile-MCP Path Traversal Attempts\u0026rdquo; to your SIEM to detect attempts to exploit this vulnerability.\u003c/li\u003e\n\u003cli\u003eMonitor application logs for unusual file access patterns or attempts to write to sensitive system directories.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T19:13:17Z","date_published":"2026-03-27T19:13:17Z","id":"/briefs/2024-01-04-mobile-mcp-path-traversal/","summary":"The @mobilenext/mobile-mcp package before version 0.0.49 is vulnerable to a Path Traversal vulnerability in the mobile_save_screenshot and mobile_start_screen_recording tools where the `saveTo` and `output` parameters are passed directly to filesystem operations without validation, potentially allowing an attacker to write files outside the intended workspace, leading to privilege escalation and persistence by overwriting sensitive host files.","title":"@mobilenext/mobile-mcp Path Traversal Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-04-mobile-mcp-path-traversal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["openclaw","symlink-traversal","vulnerability","npm","rce","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe \u003ccode\u003eopenclaw\u003c/code\u003e npm package is vulnerable to a symlink traversal vulnerability (CVE-2026-32013) affecting versions 2026.2.22 and earlier. The vulnerability lies in the \u003ccode\u003eagents.create\u003c/code\u003e and \u003ccode\u003eagents.update\u003c/code\u003e handlers within the \u003ccode\u003esrc/gateway/server-methods/agents.ts\u003c/code\u003e file. These handlers use \u003ccode\u003efs.appendFile\u003c/code\u003e on the \u003ccode\u003eIDENTITY.md\u003c/code\u003e file without proper symlink containment checks. An attacker capable of placing a symlink within the agent workspace can redirect the \u003ccode\u003eIDENTITY.md\u003c/code\u003e path to point to arbitrary files on the system, allowing them to append attacker-controlled content to these files. This can lead to serious consequences such as remote code execution by modifying \u003ccode\u003e/etc/crontab\u003c/code\u003e, persistent code execution by modifying shell configuration files like \u003ccode\u003e~/.bashrc\u003c/code\u003e, or unauthorized SSH access by modifying \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the agent workspace.\u003c/li\u003e\n\u003cli\u003eThe attacker plants a symbolic link named \u003ccode\u003eIDENTITY.md\u003c/code\u003e within the agent workspace. This symlink points to a sensitive system file, such as \u003ccode\u003e/etc/crontab\u003c/code\u003e or \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eensureAgentWorkspace\u003c/code\u003e function is called, but the exclusive-create flag (\u003ccode\u003ewx\u003c/code\u003e) skips creation due to the existing symlink (EEXIST error).\u003c/li\u003e\n\u003cli\u003eThe attacker triggers the \u003ccode\u003eagents.create\u003c/code\u003e or \u003ccode\u003eagents.update\u003c/code\u003e API endpoint, for example, by sending an HTTP POST request.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eagents.create\u003c/code\u003e or \u003ccode\u003eagents.update\u003c/code\u003e handler constructs the path to \u003ccode\u003eIDENTITY.md\u003c/code\u003e using \u003ccode\u003epath.join(workspaceDir, DEFAULT_IDENTITY_FILENAME)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003efs.appendFile\u003c/code\u003e function is called to append agent metadata (name, emoji, avatar) to the \u003ccode\u003eIDENTITY.md\u003c/code\u003e file. Because \u003ccode\u003efs.appendFile\u003c/code\u003e follows symlinks, the content is written to the attacker-controlled target file.\u003c/li\u003e\n\u003cli\u003eAttacker-controlled data is appended to the target file.\u003c/li\u003e\n\u003cli\u003eIf the target file is a cron configuration file, this leads to remote code execution. If it\u0026rsquo;s an SSH authorized_keys file, this leads to unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows an attacker to append attacker-controlled content to arbitrary files on the system. This can lead to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRemote Code Execution:\u003c/strong\u003e By appending malicious entries to \u003ccode\u003e/etc/crontab\u003c/code\u003e or user crontab files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistent Code Execution:\u003c/strong\u003e By modifying shell configuration files like \u003ccode\u003e~/.bashrc\u003c/code\u003e or \u003ccode\u003e~/.profile\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized SSH Access:\u003c/strong\u003e By appending SSH keys to \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Disruption:\u003c/strong\u003e By modifying application configuration files.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe vulnerability affects \u003ccode\u003eopenclaw\u003c/code\u003e versions 2026.2.22 and earlier, and no patches are currently available. The number of affected systems depends on the adoption rate of the \u003ccode\u003eopenclaw\u003c/code\u003e package.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor file creation events within agent workspace directories for the creation of symbolic links using file_event logs.\u003c/li\u003e\n\u003cli\u003eImplement and deploy the provided Sigma rule to detect exploitation attempts by monitoring \u003ccode\u003efs.appendFile\u003c/code\u003e calls related to IDENTITY.md without symlink resolution.\u003c/li\u003e\n\u003cli\u003eRestrict access to the agent workspace directory to prevent attackers from planting symlinks.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of \u003ccode\u003eopenclaw\u003c/code\u003e when available.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T14:00:00Z","date_published":"2026-03-27T14:00:00Z","id":"/briefs/2026-03-openclaw-symlink/","summary":"OpenClaw is vulnerable to symlink traversal via IDENTITY.md appendFile in agents.create/update. An attacker who can place a symlink in the agent workspace can hijack the IDENTITY.md path to append attacker-controlled content to arbitrary files on the system leading to remote code execution, persistent code execution, unauthorized SSH access, or service disruption.","title":"OpenClaw Symlink Traversal via IDENTITY.md appendFile in agents.create/update","url":"https://feed.craftedsignal.io/briefs/2026-03-openclaw-symlink/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["registry","symlink","race-condition","accessibility","privilege-escalation","persistence","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eRegPwnBOF is an exploit leveraging a registry symlink race condition within the Windows Accessibility ATConfig mechanism. This vulnerability allows an unprivileged user to manipulate protected areas of the registry, specifically HKLM, which are typically reserved for administrators or system processes. By exploiting this race condition, an attacker can write arbitrary values to these protected keys. The initial report surfaced around March 2026, highlighting the potential for unauthorized persistence and privilege escalation. This circumvents standard Windows security controls, posing a significant risk to system integrity and confidentiality. The exploit\u0026rsquo;s accessibility to non-administrator users makes it particularly dangerous in environments where least-privilege principles are not strictly enforced.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unprivileged user initiates the ATConfig mechanism within the Windows Accessibility features.\u003c/li\u003e\n\u003cli\u003eThe exploit creates a registry symlink pointing to a protected HKLM key.\u003c/li\u003e\n\u003cli\u003eA race condition is triggered during the ATConfig process, allowing the exploit to bypass security checks.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages this race condition to overwrite the target HKLM registry key with arbitrary data.\u003c/li\u003e\n\u003cli\u003eThe modified registry key is used to establish persistence, for example, by creating a Run key.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user login, the malicious payload associated with the modified Run key is executed.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges by executing code within the context of a privileged process.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry modifications targeting HKLM keys, especially those related to Accessibility features, using a process_creation log source and the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and least-privilege principles to limit the ability of unprivileged users to interact with system-level configurations.\u003c/li\u003e\n\u003cli\u003eInvestigate any unusual registry symlink creation events using file_event logs, particularly those involving the ATConfig mechanism, to identify potential RegPwnBOF exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-19T05:23:44Z","date_published":"2026-03-19T05:23:44Z","id":"/briefs/2024-01-regpwnbof/","summary":"RegPwnBOF exploits a registry symlink race condition in the Windows Accessibility ATConfig mechanism, enabling a normal user to write arbitrary values to protected HKLM registry keys for persistence and privilege escalation.","title":"RegPwnBOF Registry Symlink Race Condition Exploit","url":"https://feed.craftedsignal.io/briefs/2024-01-regpwnbof/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["azure","entra_id","federated_identity","persistence","privilege_escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies modifications to the issuer URL within a federated identity credential on an Entra ID application. Federated identity credentials enable applications to authenticate using tokens from external identity providers (e.g., GitHub Actions, AWS) without managing secrets. An attacker can exploit this by changing the issuer to an attacker-controlled identity provider, enabling them to generate valid tokens and authenticate as the application\u0026rsquo;s service principal. This technique provides persistent access to Azure resources with the application\u0026rsquo;s permissions, effectively bypassing traditional secret-based authentication. The detection logic focuses on the \u0026ldquo;Update application\u0026rdquo; event within Entra ID audit logs, specifically targeting changes to the \u0026ldquo;FederatedIdentityCredentials\u0026rdquo; property. It is applicable to environments using Azure and Entra ID and is relevant for defenders aiming to prevent unauthorized access and maintain the integrity of their cloud infrastructure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an Entra ID account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Entra ID portal or uses PowerShell/Azure CLI to locate a target application with federated identity credentials configured.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u0026ldquo;Issuer\u0026rdquo; URL of an existing Federated Identity Credential within the application registration. They replace the legitimate issuer URL with a URL controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their own identity provider to issue tokens that match the application\u0026rsquo;s expected audience and subject claims.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious token from their identity provider, impersonating the legitimate service principal.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the crafted token to authenticate to Azure resources, bypassing normal authentication controls.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the application\u0026rsquo;s permissions to access sensitive data, modify configurations, or deploy malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure environment by continuing to use the compromised federated identity configuration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized modifications to federated identity credential issuers in Entra ID (\u003ccode\u003eEntra ID Federated Identity Credential Issuer Modified\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eazure.auditlogs.properties.initiated_by.user.userPrincipalName\u003c/code\u003e and \u003ccode\u003eipAddress\u003c/code\u003e logs to determine the source of detected changes, as recommended in the rule\u0026rsquo;s triage notes.\u003c/li\u003e\n\u003cli\u003eImplement conditional access policies and PIM (Privileged Identity Management) to protect application management operations within Entra ID, as suggested in the rule\u0026rsquo;s response and remediation guidance.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-18T21:22:55Z","date_published":"2026-03-18T21:22:55Z","id":"/briefs/2026-03-entra-id-federated-issuer-modified/","summary":"Modification of the issuer URL of a federated identity credential in Entra ID can allow an attacker to authenticate as the application's service principal, granting persistent access to Azure resources by pointing to an attacker-controlled identity provider and bypassing normal authentication.","title":"Entra ID Federated Identity Credential Issuer Modified","url":"https://feed.craftedsignal.io/briefs/2026-03-entra-id-federated-issuer-modified/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["persistence","linux","dfir"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePersistnux is a bash-based tool designed to aid security analysts and incident responders in identifying Linux persistence mechanisms employed by attackers. Developed by 0xblake, this tool streamlines the process of detecting various persistence techniques on compromised Linux systems. Persistnux performs comprehensive checks across the system, generating detailed reports in both CSV and JSONL formats for further analysis. Its key feature is its dependency-free operation, relying solely on built-in Linux tools, making it easily deployable on live systems. The tool focuses on detecting known methods used to maintain access, offering a valuable resource for defenders. It uses indicators and confidence scoring to highlight suspicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a Linux system through methods such as exploiting vulnerabilities or using stolen credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e Once inside, the attacker attempts to escalate privileges to gain root access using exploits or misconfigurations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence Establishment:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInit Script Modification:\u003c/strong\u003e The attacker modifies init scripts located in \u003ccode\u003e/etc/init.d/\u003c/code\u003e or \u003ccode\u003e/etc/rc.d/\u003c/code\u003e to execute malicious code during system startup.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCron Job Manipulation:\u003c/strong\u003e The attacker schedules malicious tasks using cron jobs by adding entries to \u003ccode\u003e/etc/crontab\u003c/code\u003e or user-specific crontab files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSystemd Service Modification:\u003c/strong\u003e The attacker creates or modifies systemd service files in \u003ccode\u003e/etc/systemd/system/\u003c/code\u003e to execute malicious code as a service.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReverse Shell Installation:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Activity:\u003c/strong\u003e With persistent access established, the attacker proceeds to exfiltrate sensitive data, deploy ransomware, or perform other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule for detecting init script modifications to identify potential persistence attempts (reference: Sigma rule for init script modification).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule for detecting cron job modifications to identify potential persistence attempts (reference: Sigma rule for cron job modification).\u003c/li\u003e\n\u003cli\u003eRegularly audit systemd service configurations for unauthorized modifications using the Sigma rule (reference: Sigma rule for systemd service modification).\u003c/li\u003e\n\u003cli\u003eUse Persistnux or similar tools to regularly scan systems for known persistence mechanisms and review the generated reports (reference: Persistnux tool).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-17T12:00:00Z","date_published":"2026-03-17T12:00:00Z","id":"/briefs/2026-03-persistnux-tool/","summary":"Persistnux is a bash-based tool designed to identify known Linux persistence mechanisms used by attackers to maintain access to compromised systems, generating detailed reports for DFIR analysis.","title":"Persistnux - Linux Persistence Detection Tool","url":"https://feed.craftedsignal.io/briefs/2026-03-persistnux-tool/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, sourced from Elastic\u0026rsquo;s detection-rules repository, focuses on identifying malicious activity within Kubernetes environments. Specifically, it targets the creation, update, or patching of Roles and ClusterRoles that introduce high-risk RBAC permissions. These permissions include wildcard access (e.g., \u003ccode\u003e*\u003c/code\u003e) and escalation verbs such as \u003ccode\u003ebind\u003c/code\u003e, \u003ccode\u003eescalate\u003c/code\u003e, or \u003ccode\u003eimpersonate\u003c/code\u003e. The rule leverages audit logs to monitor these actions and flags those that could lead to privilege escalation or unauthorized access. The rule aims to detect attackers attempting to add a new ClusterRole with \u003ccode\u003e*\u003c/code\u003e verbs/resources and then using it to bind themselves or a service account to cluster-admin–equivalent access. This is important because attackers can silently expand privileges and enable persistence or lateral movement across the cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new ClusterRole or Role with broad permissions, including wildcard verbs and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker may use \u003ccode\u003ekubectl\u003c/code\u003e or a similar tool to apply a YAML manifest defining the malicious role.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request to create the role, and the audit logging system captures the event.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server logs the creation or modification of the RoleBinding or ClusterRoleBinding.\u003c/li\u003e\n\u003cli\u003eWith 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.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these elevated privileges to establish persistence within the cluster and potentially move laterally to other resources or environments.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Creation or Modification of Sensitive Role\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious RBAC changes (rule.name).\u003c/li\u003e\n\u003cli\u003eMonitor 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).\u003c/li\u003e\n\u003cli\u003eImplement RBAC guardrails, such as OPA Gatekeeper or Kyverno policies, to prevent the creation of overly permissive roles (references).\u003c/li\u003e\n\u003cli\u003eRestrict who can create or update RBAC objects and require all RBAC changes to go through code review and signed GitOps automation (references).\u003c/li\u003e\n\u003cli\u003eRegularly review existing Roles and ClusterRoles to identify and remove any unnecessary or overly broad permissions.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging on nodes to enhance detection capabilities around kubectl usage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-05T13:13:30Z","date_published":"2026-03-05T13:13:30Z","id":"/briefs/2026-03-kubernetes-role-modification/","summary":"This rule detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2026-03-kubernetes-role-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Compute Cloud (EC2)"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","ec2","keypair","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe unauthorized import of SSH key pairs into Amazon Elastic Compute Cloud (EC2) is a technique that malicious actors can leverage to gain unauthorized access to EC2 instances. By importing their own key pairs, attackers can bypass existing security measures and gain persistent access to compromised systems. This activity is often part of a broader attack campaign aimed at compromising sensitive data, disrupting services, or establishing a foothold within an organization\u0026rsquo;s cloud infrastructure. The initial publication of the detection rule was in December 2024, highlighting the ongoing relevance of this technique in cloud security. Monitoring for this activity can help defenders identify and respond to potential security breaches in a timely manner.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances to identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eImportKeyPair\u003c/code\u003e API call within the EC2 service to import the generated or obtained SSH key pair.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the EC2 instance\u0026rsquo;s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.\u003c/li\u003e\n\u003cli\u003eOnce inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eImportKeyPair\u003c/code\u003e events in CloudTrail logs (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: \u0026rsquo;ec2.amazonaws.com\u0026rsquo;, eventName: \u0026lsquo;ImportKeyPair\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eImportKeyPair\u003c/code\u003e events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-12-19T00:00:00Z","date_published":"2024-12-19T00:00:00Z","id":"/briefs/2024-12-aws-key-pair-import/","summary":"The import of SSH key pairs into AWS EC2, as detected by CloudTrail logs, may indicate unauthorized access attempts, persistence establishment, or privilege escalation by an attacker.","title":"Suspicious AWS EC2 Key Pair Import Activity","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-key-pair-import/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":true,"_cs_products":["SharePoint"],"_cs_severities":["medium"],"_cs_tags":["web-shell","persistence","windows"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers frequently deploy web shells to maintain persistence and execute arbitrary commands on compromised web servers. This rule identifies the creation of ASPX files, commonly used in Windows environments, within directories typically targeted for web shell deployment. The rule focuses on the \u0026ldquo;?:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\*\u0026rdquo; path, a common location for web server extensions and potential web shell placements. By excluding legitimate processes such as msiexec.exe and psconfigui.exe, the rule aims to detect suspicious ASPX file creation events indicative of malicious activity. The detection logic helps defenders identify potential web shell installations, allowing for timely response and remediation to prevent further compromise. This activity has been observed in exploitation attempts targeting SharePoint servers.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised web application to upload a malicious ASPX file to a directory within the web server\u0026rsquo;s file system, specifically targeting locations like \u0026ldquo;?:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\*\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe uploaded ASPX file contains malicious code designed to provide the attacker with remote access and control over the server.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe web shell allows the attacker to execute arbitrary commands on the server, potentially escalating privileges and moving laterally within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the web shell to establish persistence on the compromised server, ensuring continued access even after the initial vulnerability is patched.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the web shell to exfiltrate sensitive data from the server or to deploy additional malware and tools.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Web Shell ASPX File Creation in Common Directories\u0026rdquo; to detect suspicious ASPX file creation events, filtering out legitimate processes to reduce false positives.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 11 (File Create) to capture file creation events on Windows systems, which is a data source for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u0026ldquo;Web Shell ASPX File Creation in Common Directories\u0026rdquo; by examining the file path, creating process, and network activity around the time of the event.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious requests targeting ASPX files in common web server directories, as referenced in the rule description.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-12-14T14:30:00Z","date_published":"2024-12-14T14:30:00Z","id":"/briefs/2024-12-potential-web-shell-aspx-file-creation/","summary":"The creation of ASPX files in web server directories, excluding legitimate processes, indicates potential web shell deployment for persistence on Windows systems.","title":"Potential Web Shell ASPX File Creation","url":"https://feed.craftedsignal.io/briefs/2024-12-potential-web-shell-aspx-file-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege-escalation","windows","active directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies a user being added to an Active Directory (AD) group by the SYSTEM account (S-1-5-18). This behavior is significant because it can indicate an attacker who has successfully achieved SYSTEM level privileges on a domain controller. Attackers typically obtain SYSTEM privileges by exploiting vulnerabilities in the domain controller, or by abusing default group privileges such as those assigned to Server Operators. Once SYSTEM access is achieved, the attacker can then attempt to pivot to a domain account. This allows them to gain persistent access and control over the AD environment. Successful exploitation enables attackers to perform actions with the privileges of the compromised account, leading to potential data breaches, system compromise, and further lateral movement within the network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains initial access to the network through various means, such as phishing or exploiting a public-facing application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker exploits a vulnerability or misconfiguration on a system within the network to achieve local administrator or SYSTEM privileges.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDomain Controller Compromise:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGroup Modification:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With the newly acquired group membership, the attacker can now move laterally within the network, accessing resources and systems that were previously inaccessible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration / Impact:\u003c/strong\u003e The attacker leverages their access to locate and exfiltrate sensitive data, or to disrupt critical business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s reputation and result in regulatory fines and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Security Group Management\u0026rdquo; to generate the necessary events for detection as detailed in the \u003ca href=\"https://ela.st/audit-security-group-management\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect potential Active Directory group modifications by the SYSTEM account and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any event with event code 4728 where the SubjectUserSid is \u0026ldquo;S-1-5-18\u0026rdquo; as described in the \u003ca href=\"#overview\"\u003eoverview\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eReview the investigation guide outlined in the rule description for triage and analysis steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T23:59:00Z","date_published":"2024-11-02T23:59:00Z","id":"/briefs/2024-11-ad-group-modification-by-system/","summary":"Detection of a user being added to an Active Directory group by the SYSTEM account (S-1-5-18) can indicate an attacker with SYSTEM privileges attempting to pivot to a domain account.","title":"Active Directory Group Modification by SYSTEM Account","url":"https://feed.craftedsignal.io/briefs/2024-11-ad-group-modification-by-system/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["medium"],"_cs_tags":["github","ssh","certificate","initial-access","persistence","privilege-escalation","stealth","t1078.004"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eAttackers can abuse SSH certificate authorities in GitHub to gain unauthorized access to repositories. By creating or disabling SSH certificate requirements, attackers can bypass existing security controls and establish persistent access. This activity is logged in the GitHub audit logs, specifically when \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e actions are performed. Successful exploitation allows attackers to commit malicious code, steal sensitive data, or disrupt development workflows, impacting the integrity and confidentiality of the organization\u0026rsquo;s resources. The GitHub audit log streaming feature must be enabled to detect this activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSSH Certificate Authority Creation:\u003c/strong\u003e The attacker creates a new SSH certificate authority within the GitHub organization (\u003ccode\u003essh_certificate_authority.create\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable SSH Certificate Requirement:\u003c/strong\u003e Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (\u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e). This action allows attackers to bypass security controls that enforce SSH certificate usage.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Code Injection:\u003c/strong\u003e The attacker exfiltrates sensitive data or injects malicious code into the organization\u0026rsquo;s repositories.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s access and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).\u003c/li\u003e\n\u003cli\u003eRegularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T14:00:00Z","date_published":"2024-11-02T14:00:00Z","id":"/briefs/2024-11-github-ssh-cert-config-changed/","summary":"Attackers can modify SSH certificate configurations in GitHub organizations to gain unauthorized access, persist in the environment, escalate privileges, and operate stealthily.","title":"GitHub SSH Certificate Configuration Changed","url":"https://feed.craftedsignal.io/briefs/2024-11-github-ssh-cert-config-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","persistence","defense-evasion","suid","sgid"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThe SUID (Set User ID) and SGID (Set Group ID) bits are file permission mechanisms in Unix-like operating systems that allow a program to be executed with the privileges of the file\u0026rsquo;s owner or group, respectively. While intended for legitimate purposes, such as allowing users to perform specific administrative tasks, they can be abused by attackers to escalate privileges. Attackers can exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. This detection focuses on identifying processes running with root privileges (UID/GID 0) but initiated by non-root users, flagging potential misuse of SUID/SGID permissions on Linux systems monitored by Elastic Defend. This can indicate an attacker attempting to exploit a misconfiguration in order to escalate their privileges to root, or establish a backdoor for persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Linux system via some vulnerability or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies binaries with SUID/SGID bits set.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a vulnerable SUID/SGID binary, such as \u003ccode\u003efind\u003c/code\u003e or \u003ccode\u003enmap\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe binary executes with root privileges, even though the attacker is a non-root user.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to read sensitive files, modify system configurations, or install malicious software.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to root.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating a new SUID/SGID binary or modifying an existing one.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003ePrivilege Escalation via SUID/SGID\u003c/code\u003e to your SIEM to detect potential privilege escalation attempts.\u003c/li\u003e\n\u003cli\u003eEnable Elastic Defend integration to ensure the necessary process execution data is available.\u003c/li\u003e\n\u003cli\u003eRegularly audit SUID/SGID permissions across your Linux systems and remove unnecessary SUID/SGID bits.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by checking \u003ccode\u003eprocess.real_user.id\u003c/code\u003e and \u003ccode\u003eprocess.real_group.id\u003c/code\u003e to determine if non-root users initiated the process.\u003c/li\u003e\n\u003cli\u003eReview the process details, including \u003ccode\u003eprocess.name\u003c/code\u003e and \u003ccode\u003eprocess.args\u003c/code\u003e, to understand the nature of the executed command and its intended function.\u003c/li\u003e\n\u003cli\u003eMonitor system logs for suspicious activity around the time of the alert to identify any related actions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T12:00:00Z","date_published":"2024-11-02T12:00:00Z","id":"/briefs/2024-11-suid-sgid-privilege-escalation/","summary":"Attackers may leverage misconfigured SUID/SGID permissions on Linux systems to escalate privileges to root or establish persistence by executing processes with root privileges initiated by non-root users.","title":"Potential Privilege Escalation via SUID/SGID on Linux","url":"https://feed.craftedsignal.io/briefs/2024-11-suid-sgid-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","admission-controller","privilege-escalation","persistence","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe Kubernetes admission controller is a crucial component that governs API requests to a Kubernetes cluster. Attackers can modify mutating or validating webhook configurations to intercept and manipulate these requests. By creating, updating, or replacing these configurations, adversaries can inject malicious code, alter resource definitions, or even exfiltrate sensitive information like access credentials. This activity can lead to privilege escalation, persistence within the cluster, and ultimately, a compromise of the entire Kubernetes environment. The attacks are typically stealthy as they operate within the legitimate Kubernetes API framework, making detection challenging. This behavior is particularly concerning for organizations relying on Kubernetes for critical applications and sensitive data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfiguration Modification:\u003c/strong\u003e The attacker uses \u003ccode\u003ekubectl\u003c/code\u003e or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWebhook Deployment:\u003c/strong\u003e The malicious webhook is deployed as a service within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAPI Interception:\u003c/strong\u003e When a user or application makes an API request that matches the webhook\u0026rsquo;s defined rules, the webhook intercepts the request.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMalicious Code Injection:\u003c/strong\u003e The webhook injects malicious code or alters the API request to achieve the attacker\u0026rsquo;s objectives (e.g., granting unauthorized permissions, modifying resource configurations).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence/Privilege Escalation/Credential Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Data Exfiltration:\u003c/strong\u003e The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Admission Controller Modification\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for \u003ccode\u003ecreate\u003c/code\u003e, \u003ccode\u003edelete\u003c/code\u003e, \u003ccode\u003epatch\u003c/code\u003e, \u003ccode\u003ereplace\u003c/code\u003e, and \u003ccode\u003eupdate\u003c/code\u003e verbs on \u003ccode\u003emutatingwebhookconfigurations\u003c/code\u003e and \u003ccode\u003evalidatingwebhookconfigurations\u003c/code\u003e resources (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-kubernetes-admission-controller-modification/","summary":"An adversary modifies Kubernetes admission controller configurations to achieve persistence, escalate privileges, or gain unauthorized access to credentials within the cluster.","title":"Kubernetes Admission Controller Modification","url":"https://feed.craftedsignal.io/briefs/2024-11-kubernetes-admission-controller-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Adobe Acrobat Update Task","Sure Click","Secure Access Client","CtxsDPS.exe","Openvpn-gui.exe","Veeam Endpoint Backup","Cisco Secure Client","Concentr.exe","Receiver","AnalyticsSrv.exe","Redirector.exe","Download Navigator","Jabra Direct","Vmware Workstation","Eset Security","iTunes","Keepassxc.exe","Globalprotect","Pdf24.exe","Vmware Tools","Teams"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Adobe","HP","Intel","Acronis","Java","Citrix","OpenVPN","Veeam","Cisco","Epson","Jabra","VMware","ESET","iTunes","KeePassXC","Palo Alto Networks","PDF24"],"content_html":"\u003cp\u003eThe Windows Installer (msiexec.exe) is a legitimate system tool used for installing, updating, and removing software on Windows systems. Adversaries can abuse msiexec.exe to establish persistence mechanisms by creating malicious scheduled tasks or modifying registry run keys. This allows them to execute arbitrary code during system startup or user logon. This technique is attractive to attackers due to msiexec.exe being a trusted Windows binary, potentially evading detection by security solutions that focus on flagging unknown or suspicious processes. The use of msiexec.exe for persistence can be difficult to detect without specific monitoring rules, as it is a common and legitimate system process. This activity can be observed across various Windows versions and is frequently integrated into automated attack frameworks and scripts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised system, potentially through phishing, exploitation of a vulnerability, or stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages msiexec.exe to create a new scheduled task using the \u003ccode\u003eschtasks.exe\u003c/code\u003e command, setting it to execute a malicious script or binary.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses msiexec.exe in conjunction with \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell to modify registry keys under \u003ccode\u003eHKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\u003c/code\u003e or \u003ccode\u003eHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\u003c/code\u003e, adding a pointer to their malicious executable.\u003c/li\u003e\n\u003cli\u003eThe created scheduled task or registry entry points to a malicious payload, such as a reverse shell or a downloader.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe malicious payload executes, establishing a persistent foothold for the attacker on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker can now perform further actions, such as data exfiltration, lateral movement, or deployment of ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process creation events for msiexec.exe spawning \u003ccode\u003eschtasks.exe\u003c/code\u003e or \u003ccode\u003ereg.exe\u003c/code\u003e to create scheduled tasks or modify registry run keys (reference: rules in this brief).\u003c/li\u003e\n\u003cli\u003eImplement and tune the Sigma rules provided in this brief to detect suspicious msiexec.exe activity related to persistence mechanisms.\u003c/li\u003e\n\u003cli\u003eReview and audit existing scheduled tasks and registry run keys for any suspicious entries or anomalies.\u003c/li\u003e\n\u003cli\u003eEnable file integrity monitoring (FIM) on critical system directories, including the Windows Task Scheduler directory and registry run key locations (reference: event.category == \u0026ldquo;file\u0026rdquo; and file.path \u0026hellip; and event.category == \u0026ldquo;registry\u0026rdquo; and registry.path \u0026hellip; in the rule query).\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unauthorized or unknown executables (reference: rule query).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-09-05T14:17:05Z","date_published":"2024-09-05T14:17:05Z","id":"/briefs/2024-09-msiexec-persistence/","summary":"Adversaries may establish persistence by abusing the Windows Installer (msiexec.exe) to create scheduled tasks or modify registry run keys, allowing for malicious code execution upon system startup or user logon.","title":"Persistence via Windows Installer (Msiexec)","url":"https://feed.craftedsignal.io/briefs/2024-09-msiexec-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","execution","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThe detection rule identifies the loading of unusual DLLs by the Windows DNS Server process (dns.exe), potentially indicating the abuse of the ServerLevelPluginDll functionality, as described in public research and proof-of-concept code. This technique allows attackers to load arbitrary DLLs into the DNS service, leading to privilege escalation and remote code execution with SYSTEM privileges. The rule focuses on detecting unsigned or untrusted DLLs loaded by dns.exe, highlighting potential exploitation attempts and unauthorized modifications to the DNS service. Successful exploitation grants the attacker elevated privileges, allowing them to perform malicious actions on the system. The rule is designed for data generated by Elastic Defend and supports Sysmon Event ID 7 (Image Loaded) as an additional data source.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system through unspecified means.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the DNS Server configuration to enable the loading of server-level plugin DLLs.\u003c/li\u003e\n\u003cli\u003eThe attacker places a malicious, unsigned DLL in a location accessible to the DNS service.\u003c/li\u003e\n\u003cli\u003eThe DNS service (dns.exe) loads the malicious DLL upon startup or configuration change.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL executes code within the context of the DNS service, inheriting SYSTEM privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated privileges to perform malicious actions, such as installing backdoors or modifying system settings.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring the malicious DLL is loaded on subsequent system restarts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Unsigned DLL loaded by DNS Service\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnsure Sysmon Event ID 7 (Image Loaded) is enabled to provide the necessary data for the detection rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the DLL file path and code signature status.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate the DNS server configuration to ensure that only trusted DLLs are loaded.\u003c/li\u003e\n\u003cli\u003eImplement code signing policies to prevent the loading of unsigned DLLs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"/briefs/2024-07-unsigned-dns-dll-load/","summary":"The rule identifies the loading of unusual or unsigned DLLs by the DNS Server process, which can indicate exploitation of the ServerLevelPluginDll functionality, potentially leading to privilege escalation and remote code execution with SYSTEM privileges.","title":"Unsigned DLL Loaded by DNS Service","url":"https://feed.craftedsignal.io/briefs/2024-07-unsigned-dns-dll-load/"},{"_cs_actors":[],"_cs_cves":[{"cvss":10,"id":"CVE-2024-1709"},{"cvss":8.4,"id":"CVE-2024-1708"}],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","ScreenConnect"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","defense-evasion","execution","persistence","screenconnect"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of suspicious activities related to the ScreenConnect remote access tool. ScreenConnect is a legitimate remote support software, but adversaries can exploit it to execute unauthorized commands on compromised systems. This detection identifies suspicious child processes spawned by ScreenConnect client processes, such as \u003ccode\u003eScreenConnect.ClientService.exe\u003c/code\u003e or \u003ccode\u003eScreenConnect.WindowsClient.exe\u003c/code\u003e, which can indicate malicious activities such as spawning PowerShell or cmd.exe with unusual arguments. This activity can indicate potential abuse of remote access capabilities, leading to data exfiltration, command and control communication, or the establishment of persistence mechanisms. Recent exploitation of CVE-2024-1709 and CVE-2024-1708 have highlighted the risk associated with ScreenConnect exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker uses ScreenConnect to connect to the compromised system remotely.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the ScreenConnect interface to execute commands on the remote system.\u003c/li\u003e\n\u003cli\u003eThe attacker spawns a command interpreter, such as \u003ccode\u003ecmd.exe\u003c/code\u003e, using ScreenConnect. This process is a child process of the ScreenConnect client process.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ecmd.exe\u003c/code\u003e to execute malicious commands, such as downloading and executing a malicious payload.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker spawns \u003ccode\u003epowershell.exe\u003c/code\u003e with encoded commands or commands to download and execute malicious payloads from a remote server.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating a scheduled task using \u003ccode\u003eschtasks.exe\u003c/code\u003e or creates a new service using \u003ccode\u003esc.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools like \u003ccode\u003enet.exe\u003c/code\u003e to modify user accounts or privileges to maintain access to the compromised system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives, but the impact can be significant for organizations relying on ScreenConnect for remote support.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM to detect suspicious child processes spawned by ScreenConnect and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for ScreenConnect client processes spawning suspicious child processes like \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003enet.exe\u003c/code\u003e, \u003ccode\u003eschtasks.exe\u003c/code\u003e, \u003ccode\u003esc.exe\u003c/code\u003e, \u003ccode\u003erundll32.exe\u003c/code\u003e, \u003ccode\u003emshta.exe\u003c/code\u003e, \u003ccode\u003ecertutil.exe\u003c/code\u003e, \u003ccode\u003ewscript.exe\u003c/code\u003e, \u003ccode\u003ecscript.exe\u003c/code\u003e, \u003ccode\u003ecurl.exe\u003c/code\u003e, \u003ccode\u003essh.exe\u003c/code\u003e, \u003ccode\u003escp.exe\u003c/code\u003e, \u003ccode\u003ewevtutil.exe\u003c/code\u003e, \u003ccode\u003ewget.exe\u003c/code\u003e, or \u003ccode\u003ewmic.exe\u003c/code\u003e as detailed in the Sigma rules.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process-creation logging to capture the necessary process execution data to activate the rules above.\u003c/li\u003e\n\u003cli\u003eReview and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like \u003ccode\u003enet.exe\u003c/code\u003e as described in the attack chain.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-16T16:10:00Z","date_published":"2024-05-16T16:10:00Z","id":"/briefs/2024-05-screenconnect-child-process/","summary":"This rule identifies suspicious child processes spawned by ScreenConnect client processes, potentially indicating unauthorized access and command execution abusing ScreenConnect remote access software to perform malicious activities such as data exfiltration or establishing persistence.","title":"Suspicious ScreenConnect Client Child Process Activity","url":"https://feed.craftedsignal.io/briefs/2024-05-screenconnect-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Engine"],"_cs_severities":["high"],"_cs_tags":["okta","identity","privilege-escalation","persistence","defense-evasion","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unusual behaviors within the Okta Admin Console, as identified by Okta\u0026rsquo;s heuristics. While the specific campaign details are unknown, identifying anomalous access patterns to the Admin Console is crucial for detecting various malicious activities. This includes potential privilege escalation by compromised accounts or insider threats attempting to gain elevated permissions, establishing persistence through unauthorized modifications, evading existing security controls, or gaining initial access through account compromise. The detection relies on Okta\u0026rsquo;s system logs which can signal unusual administrative activity. Defenders should prioritize monitoring and alerting on these events to quickly identify and respond to potential security breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta account, possibly through credential phishing or brute-force attacks.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to the Okta Admin Console.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s behavior detection engine analyzes the login attempt, considering factors like the user\u0026rsquo;s location, device, and time of day.\u003c/li\u003e\n\u003cli\u003eThe system logs record a \u003ccode\u003epolicy.evaluate_sign_on\u003c/code\u003e event when a sign-on policy is evaluated.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003etarget.displayName\u003c/code\u003e field within the log specifies \u0026ldquo;Okta Admin Console\u0026rdquo; indicating the user is attempting to access the administrative interface.\u003c/li\u003e\n\u003cli\u003eIf Okta identifies the behavior as unusual, the \u003ccode\u003edebugContext.debugData.behaviors\u003c/code\u003e or \u003ccode\u003edebugContext.debugData.logOnlySecurityData\u003c/code\u003e fields will contain \u0026ldquo;POSITIVE\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eAn alert is triggered based on the identified unusual behavior.\u003c/li\u003e\n\u003cli\u003eThe attacker, if successful in bypassing initial checks, may proceed to create new admin accounts, modify existing policies, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eOkta Admin Console Unusual Behavior\u003c/code\u003e to your SIEM to detect suspicious Okta Admin Console access based on Okta\u0026rsquo;s internal behavior analysis.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine if the unusual behavior is legitimate or indicative of malicious activity.\u003c/li\u003e\n\u003cli\u003eReview Okta\u0026rsquo;s System Log API documentation to understand the various event types and data fields available for monitoring and detection.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta accounts, especially administrator accounts, to mitigate the risk of account compromise (related to initial access).\u003c/li\u003e\n\u003cli\u003eMonitor Okta\u0026rsquo;s security advisories and announcements for updates on emerging threats and recommended security practices (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T10:00:00Z","date_published":"2024-05-02T10:00:00Z","id":"/briefs/2024-05-okta-admin-console-behaviors/","summary":"This brief details detection of anomalous activity within the Okta Admin Console, potentially indicating privilege escalation, persistence, defense evasion, or initial access attempts by malicious actors.","title":"Okta Admin Console Unusual Behavior Detection","url":"https://feed.craftedsignal.io/briefs/2024-05-okta-admin-console-behaviors/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","certificate-based-authentication","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCertificate-Based Authentication (CBA) in Azure Active Directory allows users and services to authenticate using digital certificates instead of passwords. While intended to enhance security, misconfiguration or malicious use of CBA can lead to significant security risks. Attackers can exploit CBA to gain unauthorized access, establish persistent footholds, and escalate privileges within the Azure environment. This involves manipulating authentication policies to favor or require certificate authentication, potentially bypassing other security controls. Detection of CBA enablement is crucial as it can be a precursor to more sophisticated attacks targeting cloud resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure AD account with sufficient privileges to modify authentication policies (e.g., Global Administrator).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the Azure AD authentication methods policy to enable certificate-based authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a certificate authority (CA) in Azure AD, which will be used to issue certificates for authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts or compromises a certificate that is trusted by the registered CA.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the crafted certificate to authenticate to Azure AD, bypassing traditional password-based authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly gained access to provision new resources, modify existing configurations, or access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule to detect when certificate-based authentication is enabled in Azure AD (\u003ccode\u003eAuthentication Methods Policy Update\u003c/code\u003e in Audit Logs).\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for modifications to authentication methods policies, paying close attention to changes related to certificate-based authentication.\u003c/li\u003e\n\u003cli\u003eImplement strong certificate management practices, including proper key storage, certificate revocation, and monitoring of certificate usage.\u003c/li\u003e\n\u003cli\u003eInvestigate any unexpected changes to Azure AD authentication policies or the registration of new certificate authorities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T14:30:00Z","date_published":"2024-04-29T14:30:00Z","id":"/briefs/2024-04-azure-ad-cba-enabled/","summary":"Enabling certificate-based authentication (CBA) in Azure Active Directory can be abused by attackers to establish persistence, escalate privileges, and impair defenses.","title":"Azure AD Certificate-Based Authentication Enabled","url":"https://feed.craftedsignal.io/briefs/2024-04-azure-ad-cba-enabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","SentinelOne Cloud Funnel","Microsoft Teams","Google Chrome","Mozilla Firefox","Opera","Cisco WebEx","Discord","WhatsApp","Zoom","Brave Browser","Slack","thunderbird.exe"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","SentinelOne","Microsoft","Google","Mozilla","Opera","Cisco","Discord","WhatsApp","Zoom","Brave"],"content_html":"\u003cp\u003eThis detection rule focuses on identifying suspicious child processes of communication applications such as Slack, Cisco Webex, Microsoft Teams, Discord, WhatsApp, Zoom, and Thunderbird on Windows operating systems. Attackers may attempt to masquerade as legitimate processes or exploit vulnerabilities in these applications to execute malicious code. The rule monitors for the creation of child processes by these communication apps and checks if those child processes are unexpected, untrusted, or lack a valid code signature. This detection is crucial because successful exploitation can lead to unauthorized access, data exfiltration, or further compromise of the system. The rule has been actively maintained since August 2023, with updates as recent as May 2026, indicating its relevance and ongoing refinement to address emerging threats.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser launches a communication application (e.g., Slack, Teams, Webex).\u003c/li\u003e\n\u003cli\u003eThe communication application executes a vulnerable or compromised component.\u003c/li\u003e\n\u003cli\u003eThe compromised component spawns a child process (e.g., powershell.exe, cmd.exe).\u003c/li\u003e\n\u003cli\u003eThe child process executes a malicious command or script.\u003c/li\u003e\n\u003cli\u003eThe script attempts to download additional payloads from an external source.\u003c/li\u003e\n\u003cli\u003eThe payload executes, establishing persistence through registry modification or scheduled tasks.\u003c/li\u003e\n\u003cli\u003eThe attacker gains remote access to the system.\u003c/li\u003e\n\u003cli\u003eData exfiltration or lateral movement within the network occurs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to the compromise of sensitive data, installation of malware, and potential lateral movement within the organization\u0026rsquo;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\u0026rsquo;s objectives. If successful, this attack may lead to significant financial loss, reputational damage, and disruption of business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Communication App Child Process\u003c/code\u003e to your SIEM to detect anomalous child processes spawned by communication applications and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging with command line arguments in Windows to ensure that the Sigma rule has the necessary data to function correctly (logsource: \u003ccode\u003eprocess_creation\u003c/code\u003e, product: \u003ccode\u003ewindows\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the rule and review the command line arguments of the spawned processes to identify potential malicious activity.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to restrict the execution of unauthorized applications and reduce the attack surface.\u003c/li\u003e\n\u003cli\u003eEnsure that all communication applications are updated to the latest versions to patch known vulnerabilities and reduce the risk of exploitation.\u003c/li\u003e\n\u003cli\u003eExamine 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"/briefs/2024-01-suspicious-comm-app-child-process/","summary":"The detection rule identifies suspicious child processes spawned from communication applications on Windows systems, potentially indicating masquerading or exploitation of vulnerabilities within these applications.","title":"Suspicious Child Processes from Communication Applications","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-comm-app-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers often attempt to modify file or directory ownership to bypass access controls and gain unauthorized access to sensitive data or system resources. This involves altering permissions associated with critical files or directories, granting broader access to accounts under attacker control or resetting permissions to default values which might be more permissive. This defense evasion technique can be used to establish persistence, escalate privileges, or exfiltrate data without triggering standard security alerts. The common tools used include \u003ccode\u003eicacls.exe\u003c/code\u003e and \u003ccode\u003etakeown.exe\u003c/code\u003e, typically targeting files within the \u003ccode\u003eC:\\Windows\\\u003c/code\u003e directory.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is achieved through an existing compromised account or vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003etakeown.exe /f \u0026lt;file\u0026gt;\u003c/code\u003e to take ownership of a target file or directory.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eicacls.exe \u0026lt;file\u0026gt; /reset\u003c/code\u003e to reset the ACL of the file or directory.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses \u003ccode\u003eicacls.exe \u0026lt;file\u0026gt; /grant Everyone:F\u003c/code\u003e to grant full control to everyone, weakening security.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the contents of the file, such as injecting malicious code or configuration changes.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified file for persistence, such as a modified system DLL loaded at boot.\u003c/li\u003e\n\u003cli\u003eThe system executes the malicious code when the compromised file is accessed or executed.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as maintaining persistence, escalating privileges, or executing arbitrary commands.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process execution for \u003ccode\u003eicacls.exe\u003c/code\u003e and \u003ccode\u003etakeown.exe\u003c/code\u003e with suspicious arguments targeting system files (e.g., \u003ccode\u003eC:\\Windows\\*\u003c/code\u003e) to detect potential permission modification attempts using the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eEnable Windows Security Auditing for file system changes to capture events related to permission modifications and ownership changes.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune for your environment, specifically focusing on processes modifying permissions on files within the \u003ccode\u003eC:\\Windows\\\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rules, focusing on the process execution chain and the target files being modified.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-system-file-ownership-change/","summary":"Adversaries may modify file or directory ownership to evade access control lists (ACLs) and access protected files, often using icacls.exe or takeown.exe to reset permissions on system files.","title":"System File Ownership Change for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-system-file-ownership-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","CrowdStrike Falcon","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["persistence","windows","netsh","registry"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThe \u003ccode\u003enetsh.exe\u003c/code\u003e utility in Windows supports the addition of Helper DLLs to extend its functionality. An attacker can abuse this mechanism to establish persistence by adding a malicious DLL. When \u003ccode\u003enetsh.exe\u003c/code\u003e is executed, the malicious DLL is loaded and executed, allowing the attacker to run arbitrary code with the privileges of the user or process that initiated \u003ccode\u003enetsh.exe\u003c/code\u003e. This can be done by administrators or scheduled tasks, making it a stealthy and effective persistence technique. The registry key targeted by this technique is \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the target system through unspecified means.\u003c/li\u003e\n\u003cli\u003eAttacker creates a malicious DLL to be used as a Netsh Helper DLL.\u003c/li\u003e\n\u003cli\u003eAttacker modifies the Windows Registry to add the malicious DLL as a Netsh Helper DLL under \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe system administrator or a scheduled task executes \u003ccode\u003enetsh.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enetsh.exe\u003c/code\u003e loads and executes the malicious DLL, granting the attacker code execution.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL performs its intended actions, such as establishing a reverse shell or deploying additional malware.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the system through the malicious Netsh Helper DLL.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry modifications under the \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e path for suspicious DLL additions using the \u0026ldquo;Netsh Helper DLL Registry Modification\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to collect the necessary data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the DLL file properties, timestamps, and related processes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-netsh-helper-dll/","summary":"Attackers may abuse the Netsh Helper DLL functionality by adding malicious DLLs to execute payloads every time the netsh utility is executed via administrators or scheduled tasks, achieving persistence.","title":"Netsh Helper DLL Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-netsh-helper-dll/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","persistence","privilege-escalation","initial-access"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis detection identifies the creation of new secrets within GitHub Actions. Threat actors may create or modify secrets to gain unauthorized access, establish persistence, or escalate privileges within the GitHub environment. The activity is captured via GitHub\u0026rsquo;s audit logs. The scope of this detection encompasses the creation of secrets at the organization, environment, codespaces, or repository level. Successful detection of this activity allows security teams to investigate potentially malicious modifications to GitHub Actions secrets, which could lead to supply chain compromise or data exfiltration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings for the organization, environment, codespaces, or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.\u003c/li\u003e\n\u003cli\u003eThe secret is stored within GitHub\u0026rsquo;s infrastructure, accessible to GitHub Actions workflows.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.\u003c/li\u003e\n\u003cli\u003eThe workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable GitHub audit log streaming to capture the events necessary for this detection (see \u003ccode\u003elogsource\u003c/code\u003e definition).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGithub New Secret Created\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u0026ldquo;actor\u0026rdquo; involved in creating the secret.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-github-secret-creation/","summary":"This analytic detects the creation of new GitHub Actions secrets at the organization, environment, codespaces, or repository level, potentially indicating malicious persistence or privilege escalation.","title":"Detection of New GitHub Actions Secrets Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-github-secret-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","execution","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may leverage scripting engines, such as \u003ccode\u003ewscript.exe\u003c/code\u003e and \u003ccode\u003ecscript.exe\u003c/code\u003e, to directly modify the Windows Registry. These scripting engines are often abused for malicious purposes, including establishing persistence, escalating privileges, or disabling security controls. These scripting engines can modify the registry without using standard tools like \u003ccode\u003eregedit.exe\u003c/code\u003e or \u003ccode\u003ereg.exe\u003c/code\u003e, making it harder to detect malicious registry changes. Defenders should be aware of processes using these engines to modify the registry, as this behavior is uncommon in legitimate software installations or administrative tasks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system, potentially through social engineering or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script (VBScript, JScript) via \u003ccode\u003ewscript.exe\u003c/code\u003e or \u003ccode\u003ecscript.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe script contains commands to modify specific registry keys, such as the Run key for persistence (T1547.001).\u003c/li\u003e\n\u003cli\u003eThe scripting engine process (e.g., \u003ccode\u003ewscript.exe\u003c/code\u003e) directly interacts with the Windows Registry to set the new values.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user logon, the modified registry key triggers the execution of a malicious payload.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence on the compromised system, allowing for continued access and control.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the persistent access to perform lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; to your SIEM to detect suspicious registry modifications made by scripting engines.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; for unusual or unauthorized registry changes.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for modifications made by processes such as \u003ccode\u003ewscript.exe\u003c/code\u003e and \u003ccode\u003ecscript.exe\u003c/code\u003e (logsource: registry_event).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-susp-reg-mod/","summary":"The use of scripting engines like WScript and CScript to modify the Windows registry can indicate an attempt to bypass standard tools and evade defenses, potentially for persistence or other malicious activities.","title":"Suspicious Registry Modifications by Scripting Engines","url":"https://feed.craftedsignal.io/briefs/2024-01-29-susp-reg-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike"],"_cs_severities":["low"],"_cs_tags":["persistence","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThe \u0026ldquo;Office Test\u0026rdquo; registry key, located under \u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\u003c/code\u003e, is a legitimate feature that allows specifying a DLL to be executed every time an MS Office application is started. Attackers can abuse this functionality by modifying the registry to point to a malicious DLL, achieving persistence on a compromised host. This allows for continued malicious activity even after a system restart or user logout. Elastic has published a rule to detect this behavior. The modification of this registry key, excluding deletions, is a strong indicator of potential abuse, and can be detected via endpoint detection and response (EDR) solutions as well as traditional Sysmon logging.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system, often through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes a foothold and escalates privileges to make necessary registry modifications.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\u003c/code\u003e registry key, adding a new entry or modifying an existing one to point to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.\u003c/li\u003e\n\u003cli\u003eA user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).\u003c/li\u003e\n\u003cli\u003eThe Office application loads the DLL specified in the \u0026ldquo;Office Test\u0026rdquo; registry key during startup.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the \u0026ldquo;Office Test\u0026rdquo; registry key (\u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\\*\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.\u003c/li\u003e\n\u003cli\u003eMonitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T17:30:00Z","date_published":"2024-01-27T17:30:00Z","id":"/briefs/2024-01-office-test-registry-persistence/","summary":"Attackers modify the Microsoft Office 'Office Test' Registry key to achieve persistence by specifying a malicious DLL that executes upon application startup.","title":"Microsoft Office 'Office Test' Registry Persistence Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-office-test-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Elastic Defend","Microsoft Defender XDR"],"_cs_severities":["medium"],"_cs_tags":["persistence","execution","privilege_escalation","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eAttackers may configure existing Windows services or create new ones to execute system shells, in order to elevate their privileges from administrator to SYSTEM. This tactic is used to gain SYSTEM permissions and establish persistence. The detection rule focuses on identifying instances where \u003ccode\u003eservices.exe\u003c/code\u003e is the parent process of a command shell (cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe), indicating that a service is being abused to run a shell. The rule is designed to work with data from Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the system with administrator privileges.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a legitimate service or creates a new service to abuse for privilege escalation.\u003c/li\u003e\n\u003cli\u003eAttacker 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\u0026rsquo;s executable path or adding command-line arguments.\u003c/li\u003e\n\u003cli\u003eThe system\u0026rsquo;s Service Control Manager (SCM) starts the service.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eservices.exe\u003c/code\u003e spawns the configured command shell process.\u003c/li\u003e\n\u003cli\u003eThe command shell executes with SYSTEM privileges.\u003c/li\u003e\n\u003cli\u003eAttacker uses the SYSTEM shell to perform malicious activities, such as installing malware, accessing sensitive data, or creating new user accounts.\u003c/li\u003e\n\u003cli\u003eThe service continues to run, providing persistent access to the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSystem Shells via Services\u003c/code\u003e to detect the execution of command shells spawned by \u003ccode\u003eservices.exe\u003c/code\u003e within your SIEM environment, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any process creation events where \u003ccode\u003eservices.exe\u003c/code\u003e is the parent process of \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003epwsh.exe\u003c/code\u003e, or \u003ccode\u003epowershell_ise.exe\u003c/code\u003e using the investigation guide provided in the content section.\u003c/li\u003e\n\u003cli\u003eReview service creation and modification events in Windows Event Logs (Event IDs 4697 and 7045) for suspicious entries.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging (Event ID 1) to capture detailed process information.\u003c/li\u003e\n\u003cli\u003eUtilize osquery to retrieve detailed service information to identify potentially malicious services. Reference queries $osquery_0, $osquery_1, and $osquery_2 in the investigation guide.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-system-shells-via-services/","summary":"Attackers may configure existing services or create new ones to execute system shells to elevate their privileges from administrator to SYSTEM, using services.exe as the parent process of the shell.","title":"System Shells Launched via Windows Services","url":"https://feed.craftedsignal.io/briefs/2024-01-system-shells-via-services/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["persistence","browser-extension","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne"],"content_html":"\u003cp\u003eThis detection rule identifies the installation of browser extensions on Windows systems, which can be a sign of malicious activity. Threat actors may install malicious browser extensions through app store downloads disguised as legitimate extensions, social engineering tactics, or by directly compromising a system. These extensions can then be used for persistence, data theft, or other malicious purposes. The rule focuses on monitoring file creation events related to browser extension installations, specifically targeting the file paths and types associated with Firefox (.xpi) and Chromium-based browsers (.crx). It excludes known safe processes and extensions to reduce false positives. This detection is relevant for defenders because malicious browser extensions can provide a persistent foothold for attackers, allowing them to maintain access to compromised systems and user data. The rule is based on EQL and can be used with Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe user\u0026rsquo;s system is compromised, potentially through social engineering or existing malware.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the system and attempts to install a malicious browser extension.\u003c/li\u003e\n\u003cli\u003eThe attacker drops the extension file (.xpi for Firefox, .crx for Chromium) into the appropriate browser extension directory (e.g., \u003ccode\u003eC:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\*\\\\Profiles\\\\*\\\\Extensions\\\\\u003c/code\u003e for Firefox or \u003ccode\u003eC:\\\\Users\\\\*\\\\AppData\\\\Local\\\\*\\\\*\\\\User Data\\\\Webstore Downloads\\\\\u003c/code\u003e for Chromium).\u003c/li\u003e\n\u003cli\u003eA file creation event is triggered as the extension file is created in the target directory.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies this file creation event based on the file name and path, filtering out known safe processes like firefox.exe.\u003c/li\u003e\n\u003cli\u003eThe malicious extension installs itself into the browser.\u003c/li\u003e\n\u003cli\u003eThe extension gains persistence by loading every time the browser starts.\u003c/li\u003e\n\u003cli\u003eThe attacker can now perform malicious actions such as monitoring browsing activity, stealing credentials, or injecting malicious content into web pages.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon Event ID 11 (File Create) logging to capture the necessary file creation events for this detection.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eBrowser Extension Install via File Creation\u003c/code\u003e to your SIEM and tune the exclusions for your specific environment.\u003c/li\u003e\n\u003cli\u003eReview and update the list of known safe processes and extensions in the Sigma rule \u003ccode\u003eBrowser Extension Install via File Creation\u003c/code\u003e to minimize false positives.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting policies to restrict the installation of unauthorized browser extensions.\u003c/li\u003e\n\u003cli\u003eEducate users on the risks associated with installing browser extensions from untrusted sources and encourage them to only install extensions from official browser stores.\u003c/li\u003e\n\u003cli\u003eImplement policies to regularly review installed browser extensions across the organization.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-browser-extension-install/","summary":"This rule identifies the installation of potentially malicious browser extensions, which adversaries can leverage for persistence and unauthorized activity by monitoring file creation events in common browser extension directories on Windows systems.","title":"Detection of Malicious Browser Extension Installation","url":"https://feed.craftedsignal.io/briefs/2024-01-browser-extension-install/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["persistence","bits","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThe Background Intelligent Transfer Service (BITS) is a Windows service used for asynchronous, prioritized, and throttled file transfers. Attackers can abuse BITS to establish persistence by using the \u003ccode\u003eSetNotifyCmdLine\u003c/code\u003e method to execute a program after a BITS job completes or enters a specific state. This technique allows adversaries to run arbitrary code with elevated privileges, bypassing traditional security measures. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables like \u003ccode\u003eWerFaultSecure.exe\u003c/code\u003e, \u003ccode\u003eWerFault.exe\u003c/code\u003e, \u003ccode\u003ewermgr.exe\u003c/code\u003e, and \u003ccode\u003edirectxdatabaseupdater.exe\u003c/code\u003e. This behavior can be employed to maintain access to a compromised system, even after a reboot or user logout. Defenders need to monitor BITS activity for unusual command-line executions to detect and prevent potential persistence attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system through other means (e.g., phishing, exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the BITSAdmin tool or PowerShell cmdlets to create a new BITS job.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the BITS job to download a malicious payload or execute a malicious script.\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the \u003ccode\u003eSetNotifyCmdLine\u003c/code\u003e method to set a command that will be executed upon job completion or a specified state change.\u003c/li\u003e\n\u003cli\u003eThe BITS service executes the specified command, which can be a script interpreter (e.g., \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ecmd.exe\u003c/code\u003e) or a malicious executable.\u003c/li\u003e\n\u003cli\u003eThe malicious command downloads or executes further payloads, establishing persistence on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access, allowing them to execute commands, steal data, or perform other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003eSetNotifyCmdLine\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process creation events for processes spawned by \u003ccode\u003esvchost.exe\u003c/code\u003e with arguments containing \u0026ldquo;BITS\u0026rdquo; but not in the exclusion list (WerFaultSecure.exe, WerFault.exe, wermgr.exe, directxdatabaseupdater.exe) using the \u0026ldquo;Persistence via BITS Job Notify Cmdline\u0026rdquo; rule.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Suspicious BITS Job Creation\u0026rdquo; to identify unusual BITS job creation activities.\u003c/li\u003e\n\u003cli\u003eReview BITS job configurations on systems to identify and remove any unauthorized or suspicious jobs.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture detailed information about process execution, including parent-child relationships and command-line arguments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T10:00:00Z","date_published":"2024-01-26T10:00:00Z","id":"/briefs/2024-01-26-bits-persistence/","summary":"Adversaries can achieve persistence by abusing the Background Intelligent Transfer Service (BITS) SetNotifyCmdLine method to execute a program after a job finishes, leading to arbitrary code execution and system compromise.","title":"Persistence via BITS Job Notify Cmdline","url":"https://feed.craftedsignal.io/briefs/2024-01-26-bits-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Google Workspace"],"_cs_severities":["medium"],"_cs_tags":["initial-access","privilege-escalation","defense-evasion","persistence","gworkspace"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis brief focuses on detecting suspicious login activity within Google Workspace environments, as flagged by Google\u0026rsquo;s internal risk assessment mechanisms. Google Workspace logs login events and classifies them based on various risk factors, including the use of less secure applications, programmatic logins, and other anomalies. This detection capability is crucial for identifying potential compromises, unauthorized access attempts, and malicious activities within the Google Workspace ecosystem. Analyzing these flagged events allows security teams to proactively respond to threats before they escalate, preventing data breaches and maintaining the integrity of sensitive information. This alert focuses on logins classified as \u0026lsquo;suspicious_login_less_secure_app\u0026rsquo;, \u0026lsquo;suspicious_login\u0026rsquo;, and \u0026lsquo;suspicious_programmatic_login\u0026rsquo;.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains initial access using compromised credentials or brute-force techniques targeting Google Workspace accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLogin Attempt:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuspicious Activity Detection:\u003c/strong\u003e Google\u0026rsquo;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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEvent Logging:\u003c/strong\u003e Google Workspace logs the suspicious login event, including the reason for the classification (e.g., \u0026lsquo;suspicious_login_less_secure_app\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePotential Privilege Escalation:\u003c/strong\u003e Upon successful login, the attacker may attempt to escalate privileges within the Google Workspace environment to gain broader access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker might use techniques to evade detection, such as disabling security features or modifying audit logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating new accounts, modifying existing ones, or installing malicious apps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Activity:\u003c/strong\u003e The attacker uses the compromised account to exfiltrate sensitive data or perform other malicious activities, such as sending phishing emails.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s ability to escalate privileges. Targeted sectors are broad, affecting any organization relying on Google Workspace for collaboration and data storage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious login activity classified by Google Workspace (logsource: \u003ccode\u003egcp\u003c/code\u003e, service: \u003ccode\u003egoogle_workspace.login\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all Google Workspace accounts to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eDisable or restrict the use of less secure apps within Google Workspace to reduce the attack surface.\u003c/li\u003e\n\u003cli\u003eMonitor Google Workspace audit logs for other suspicious activities, such as unusual file access or data exfiltration attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T10:00:00Z","date_published":"2024-01-26T10:00:00Z","id":"/briefs/2024-01-26-gworkspace-suspicious-login/","summary":"Detect Google Workspace login activity that Google has classified as suspicious, potentially indicating initial access, privilege escalation, defense evasion, or persistence attempts.","title":"Google Workspace Suspicious Login Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-26-gworkspace-suspicious-login/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identityprovider","okta","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThe creation of a new identity provider (IdP) in Okta is a sensitive action that should be closely monitored. While legitimate administrators may create IdPs for federation purposes, adversaries can abuse this functionality to establish persistence or escalate privileges within an Okta environment. This involves creating a malicious IdP that they control and configuring it to authenticate users, potentially bypassing existing security controls such as multi-factor authentication (MFA) or implementing cross-tenant impersonation. The creation of a rogue IdP within Okta can be an indicator of compromise, potentially leading to unauthorized access to applications and data protected by Okta. Defenders should monitor Okta system logs for the creation of new identity providers and validate their legitimacy.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta tenant with sufficient administrative privileges, either through compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new identity provider (IdP) within the Okta tenant (system.idp.lifecycle.create).\u003c/li\u003e\n\u003cli\u003eThe attacker configures the rogue IdP with attacker-controlled settings, such as SAML endpoints or OIDC configurations, potentially pointing to an attacker-controlled server.\u003c/li\u003e\n\u003cli\u003eThe attacker configures routing rules within Okta to direct specific users or groups to authenticate through the newly created, malicious IdP.\u003c/li\u003e\n\u003cli\u003eUsers attempting to access Okta-protected applications are redirected to the attacker-controlled IdP for authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s IdP captures user credentials or issues fraudulent authentication tokens, allowing the attacker to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Identity Provider Created\u0026rdquo; to your SIEM to detect the creation of new identity providers and tune it for your environment.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate all configured identity providers within your Okta tenant to ensure their legitimacy.\u003c/li\u003e\n\u003cli\u003eImplement strong access controls and multi-factor authentication for all Okta administrative accounts to prevent unauthorized creation of identity providers.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious activity related to identity provider configuration and authentication.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the \u0026ldquo;Okta Identity Provider Created\u0026rdquo; Sigma rule to determine the legitimacy of the IdP creation event.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"/briefs/2024-01-okta-idp-created/","summary":"An adversary may create a rogue identity provider within Okta to establish persistence and potentially escalate privileges by impersonating legitimate users or bypassing multi-factor authentication.","title":"Okta Identity Provider Creation Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-idp-created/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","persistence","suid","sgid"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule, sourced from Elastic, identifies instances where a process executes with root privileges (UID/GID 0) while the real user/group ID is non-zero. This condition suggests that the process has been granted SUID/SGID permissions, potentially allowing it to run with elevated privileges. Attackers may exploit such misconfigurations to escalate their privileges to root or establish persistence mechanisms. The rule focuses on Linux systems and leverages Elastic Defend data to identify such events. The initial publication date of the rule was in June 2024, with updates made as recently as May 2026. This type of misconfiguration can lead to significant security breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user (non-root) executes a binary that has the SUID or SGID bit set.\u003c/li\u003e\n\u003cli\u003eThe system checks the permissions of the executable and identifies the SUID/SGID bit.\u003c/li\u003e\n\u003cli\u003eThe process spawns with the effective UID/GID set to the owner/group of the executable file (typically root).\u003c/li\u003e\n\u003cli\u003eThe process attempts to perform actions that require elevated privileges.\u003c/li\u003e\n\u003cli\u003eIf the SUID/SGID binary is vulnerable, the attacker can leverage it to execute arbitrary commands as root.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to root, gaining full control over the system.\u003c/li\u003e\n\u003cli\u003eThe attacker installs a backdoor for persistent access.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities, such as data exfiltration or system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect potential SUID/SGID exploitation (see the \u003ccode\u003erules\u003c/code\u003e section).\u003c/li\u003e\n\u003cli\u003eReview the SUID/SGID binaries identified by the rule and verify their configurations to ensure they are correctly set and necessary.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and logging for SUID/SGID execution attempts to detect and respond to similar threats in the future (Data Source: Elastic Defend).\u003c/li\u003e\n\u003cli\u003eConsider implementing stricter access controls and reducing the number of SUID/SGID binaries on the system to minimize the attack surface.\u003c/li\u003e\n\u003cli\u003eInvestigate the parent process of the flagged binaries to determine the origin of the execution and whether it aligns with expected behavior.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-24T12:00:00Z","date_published":"2024-01-24T12:00:00Z","id":"/briefs/2024-01-suid-sgid-privesc/","summary":"This rule detects potential privilege escalation attempts on Linux systems by identifying processes running with root privileges but initiated by non-root users, indicative of SUID/SGID abuse.","title":"Potential Privilege Escalation via SUID/SGID Abuse on Linux","url":"https://feed.craftedsignal.io/briefs/2024-01-suid-sgid-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Elastic Endgame","Sysmon","AA_v*.exe","AeroAdmin.exe","AnyDesk.exe","apc_Admin.exe","apc_host.exe","AteraAgent.exe","aweray_remote*.exe","AweSun.exe","AgentMon.exe","B4-Service.exe","BASupSrvc.exe","bomgar-scc.exe","domotzagent.exe","domotz-windows-x64-10.exe","dwagsvc.exe","DWRCC.exe","ImperoClientSVC.exe","ImperoServerSVC.exe","ISLLight.exe","ISLLightClient.exe","fleetdeck_commander*.exe","getscreen.exe","g2aservice.exe","GoToAssistService.exe","gotohttp.exe","jumpcloud-agent.exe","level.exe","LvAgent.exe","LMIIgnition.exe","LogMeIn.exe","Lunixar.exe","LunixarRemote.exe","LunixarUpdater.exe","ManageEngine_Remote_Access_Plus.exe","MeshAgent.exe","Mikogo-Service.exe","NinjaRMMAgent.exe","NinjaRMMAgenPatcher.exe","ninjarmm-cli.exe","parsec.exe","PService.exe","quickassist.exe","r_server.exe","radmin.exe","radmin3.exe","RCClient.exe","RCService.exe","RemoteDesktopManager.exe","RemotePC.exe","RemotePCDesktop.exe","RemotePCService.exe","rfusclient.exe","ROMServer.exe","ROMViewer.exe","RPCSuite.exe","rserver3.exe","rustdesk.exe","rutserv.exe","rutview.exe","saazapsc.exe","ScreenConnect*.exe","session_win.exe","Remote Support.exe","smpcview.exe","spclink.exe","Splashtop-streamer.exe","Syncro.Overmind.Service.exe","SyncroLive.Agent.Runner.exe","SRService.exe","strwinclt.exe","Supremo.exe","SupremoService.exe","tacticalrmm.exe","tailscale.exe","tailscaled.exe","teamviewer.exe","ToDesk_Service.exe","twingate.exe","TiClientCore.exe","TSClient.exe","tvn.exe","tvnserver.exe","tvnviewer.exe","UltraVNC*.exe","UltraViewer*.exe","vncserver.exe","vncviewer.exe","winvnc.exe","winwvc.exe","Zaservice.exe","ZohoURS.exe","Velociraptor.exe","ToolsIQ.exe","CagService.exe","ScreenConnect.ClientService.exe","TiAgent.exe","GoToResolveProcessChecker.exe","GoToResolveUnattended.exe","Syncro.Installer.exe"],"_cs_severities":["medium"],"_cs_tags":["remote-access","rmm","command-and-control","persistence"],"_cs_type":"advisory","_cs_vendors":["Elastic","Action1 Corporation","AeroAdmin LLC","Ammyy LLC","Atera Networks Ltd","AWERAY PTE. LTD.","BeamYourScreen GmbH","Bomgar Corporation","DUC FABULOUS CO.,LTD","DOMOTZ INC.","DWSNET OÜ","FleetDeck Inc","GlavSoft LLC","Hefei Pingbo Network Technology Co. Ltd","IDrive, Inc.","IMPERO SOLUTIONS LIMITED","Instant Housecall","ISL Online Ltd.","LogMeIn, Inc.","LUNIXAR SAS DE CV","MMSOFT Design Ltd.","Nanosystems S.r.l.","NetSupport Ltd","NinjaRMM, LLC","Parallels International GmbH","philandro Software GmbH","Pro Softnet Corporation","RealVNC","Remote Utilities LLC","Rocket Software, Inc.","SAFIB","Servably, Inc.","ShowMyPC INC","Splashtop Inc.","Superops Inc.","TeamViewer","Techinline Limited","uvnc bvba","Yakhnovets Denis Aleksandrovich IP","Zhou Huabing","ZOHO Corporation Private Limited","Connectwise, LLC","BreakingSecurity.net","Tailscale","Twingate","RustDesk","Zoho","JumpCloud","ScreenConnect","GoTo"],"content_html":"\u003cp\u003eAttackers commonly abuse legitimate remote monitoring and management (RMM) tools and remote access software for command and control (C2), persistence, and execution of native commands on compromised endpoints. These tools provide attackers with the ability to maintain access, execute commands, and move laterally within a network. This detection identifies when a process associated with commonly abused RMM/remote access tools is observed for the first time on a host. The rule is designed to trigger when a new process name or code signature associated with RMM software, or a child process of such software, is seen within a configured history window. This helps defenders quickly identify potentially malicious use of legitimate tools.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains initial access to a target system through various methods, such as exploiting vulnerabilities or using compromised credentials.\u003c/li\u003e\n\u003cli\u003eTool 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.\u003c/li\u003e\n\u003cli\u003ePersistence: 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.\u003c/li\u003e\n\u003cli\u003eCommand 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.\u003c/li\u003e\n\u003cli\u003eLateral 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.\u003c/li\u003e\n\u003cli\u003eData 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.\u003c/li\u003e\n\u003cli\u003eCleanup: The attacker may attempt to remove traces of their activity, such as logs or files associated with the RMM tool, to avoid detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the process creation rule to detect the execution of RMM tools on endpoints based on \u003ccode\u003eprocess.name\u003c/code\u003e and \u003ccode\u003eprocess.code_signature.subject_name\u003c/code\u003e criteria in the query.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging (Event ID 1) to ensure the collection of necessary event data for the detection rule.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-24T12:00:00Z","date_published":"2024-01-24T12:00:00Z","id":"/briefs/2024-01-first-time-seen-rmm/","summary":"Detects the execution of previously unseen remote monitoring and management (RMM) tools or remote access software on compromised Windows endpoints, often leveraged for command-and-control, persistence, and execution of malicious commands.","title":"First Time Seen Remote Monitoring and Management Tool Execution","url":"https://feed.craftedsignal.io/briefs/2024-01-first-time-seen-rmm/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta is a widely used identity and access management (IAM) platform, making it a prime target for malicious actors seeking to gain unauthorized access to sensitive resources. This threat focuses on the creation of new admin role assignments within Okta. An attacker who successfully compromises an Okta account with sufficient privileges, or bypasses security controls, may attempt to escalate their privileges or establish persistence by creating new admin role assignments for themselves or other accounts they control. This activity can go unnoticed if not actively monitored, granting the attacker extended access and control over the Okta environment and connected applications. Monitoring for anomalous admin role assignments is crucial for early detection and prevention of potential breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Attacker gains unauthorized access to an Okta account, possibly through credential phishing, brute-force attacks, or exploitation of vulnerabilities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Check:\u003c/strong\u003e The attacker verifies the privileges of the compromised account to determine if it has sufficient permissions to create new admin role assignments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Impersonation:\u003c/strong\u003e The attacker uses the compromised account to access the Okta admin dashboard.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRole Assignment Creation:\u003c/strong\u003e The attacker navigates to the role assignment section and initiates the creation of a new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfiguration:\u003c/strong\u003e The attacker specifies the target user or group for the new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit Logging:\u003c/strong\u003e Okta logs the event \u0026lsquo;iam.resourceset.bindings.add\u0026rsquo; indicating the creation of a new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOkta Admin Role Assignment Created\u003c/code\u003e to your SIEM and tune it for your environment to detect suspicious admin role creation activity in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eOkta Admin Role Assignment Created\u003c/code\u003e rule to determine if the role assignment was legitimate and authorized.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta accounts, especially those with administrative privileges, to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Okta admin role assignments to identify and remove any unnecessary or unauthorized privileges.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-okta-admin-role/","summary":"Detection of new admin role assignments in Okta, potentially indicating privilege escalation or persistence attempts by malicious actors.","title":"Okta Admin Role Assignment Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-admin-role/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers often target cloud environments to establish persistence and maintain unauthorized access. One technique involves adding their own authentication methods to compromised user accounts. By registering a new security info, such as a phone number or email address, an attacker can bypass multi-factor authentication and regain access even if the original credentials are changed. This activity is typically logged within Azure Audit Logs, specifically under the \u0026lsquo;Authentication Methods\u0026rsquo; service and \u0026lsquo;UserManagement\u0026rsquo; category. Detecting these changes is crucial for identifying potentially compromised accounts and preventing further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access to the Azure environment is gained, potentially through credential phishing or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target user account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the Azure Active Directory (Azure AD) settings for the compromised user.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the \u0026ldquo;Security info\u0026rdquo; section of the user\u0026rsquo;s profile.\u003c/li\u003e\n\u003cli\u003eThe 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 \u0026ldquo;User registered security info\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker can now use the newly added authentication method to bypass multi-factor authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to access sensitive data, applications, or resources within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure environment, even if the original account password is changed.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect changes to authentication methods within Azure audit logs (logsource: azure, service: auditlogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where the \u003ccode\u003eOperationName\u003c/code\u003e is \u003ccode\u003eUser registered security info\u003c/code\u003e in the Azure Audit Logs, as this indicates a change in authentication method.\u003c/li\u003e\n\u003cli\u003eReview the referenced Microsoft documentation on privileged account security to understand best practices for securing administrative accounts (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-azure-auth-method-change/","summary":"An attacker may add an authentication method to a compromised Azure account for persistent access, which can be detected by monitoring changes to authentication methods in Azure audit logs.","title":"Azure Authentication Method Change Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-23-azure-auth-method-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege_escalation","windows","service_creation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers frequently abuse Windows services for persistence and privilege escalation. By creating or modifying services with malicious configurations, they can execute code with SYSTEM privileges. This rule detects suspicious service creations based on the image path, looking for services that point to command interpreters, scripts, or unusual locations. This activity is indicative of malicious actors attempting to establish persistence or escalate privileges within a compromised system. The detection focuses on identifying unusual command lines and file paths associated with newly created services based on Windows Event IDs 4697 and 7045.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains initial access to the system through various means.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker attempts to escalate privileges to SYSTEM.\u003c/li\u003e\n\u003cli\u003eService Creation: The attacker creates a new Windows service using tools like \u003ccode\u003esc.exe\u003c/code\u003e or modifies an existing one.\u003c/li\u003e\n\u003cli\u003eImage Path Modification: The attacker sets the service\u0026rsquo;s \u003ccode\u003eImagePath\u003c/code\u003e to point to a command interpreter (e.g., cmd.exe, powershell.exe) or a script file.\u003c/li\u003e\n\u003cli\u003eCommand Execution: The service executes the command interpreter or script with SYSTEM privileges.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker configures the service to start automatically on system boot, ensuring persistent access.\u003c/li\u003e\n\u003cli\u003eMalicious Activity: The attacker uses the elevated privileges to perform malicious activities, such as installing malware, stealing credentials, or compromising other systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Security Event Logs and Windows System Event Logs to capture service creation events (Event IDs 4697 and 7045).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Service Installation via ImagePath\u003c/code\u003e to your SIEM to detect suspicious service creations.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the service\u0026rsquo;s \u003ccode\u003eImagePath\u003c/code\u003e and associated processes.\u003c/li\u003e\n\u003cli\u003eUse the Osquery queries provided in the source to investigate existing services, unsigned executables, and drivers for suspicious characteristics.\u003c/li\u003e\n\u003cli\u003eMonitor for registry changes related to service creation or modification.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-12T12:00:00Z","date_published":"2024-01-12T12:00:00Z","id":"/briefs/2024-01-suspicious-service-installation/","summary":"This detection identifies the creation of new Windows services with suspicious command values, often used for privilege escalation and persistence by malicious actors.","title":"Detect Suspicious Windows Service Installation","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-service-installation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","execution","windows","dll-injection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eAttackers may attempt to load malicious, unsigned DLLs into \u003ccode\u003esvchost.exe\u003c/code\u003e, a legitimate Windows service host process, to maintain persistence or escalate privileges. This technique abuses the shared service host process to execute arbitrary code with SYSTEM privileges. The \u003ccode\u003esvchost.exe\u003c/code\u003e process, which typically hosts multiple Windows services, can be targeted to load malicious DLLs from unusual file paths, potentially bypassing security measures that rely on code signing validation. This is especially concerning because \u003ccode\u003esvchost.exe\u003c/code\u003e is a trusted process, making detection more challenging. The loading of unsigned DLLs by \u003ccode\u003esvchost.exe\u003c/code\u003e from atypical directories is a strong indicator of potential malicious activity, as legitimate Windows services rarely load unsigned libraries from such locations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn adversary gains initial access to the system through an undisclosed method (e.g., exploitation of a vulnerability or social engineering).\u003c/li\u003e\n\u003cli\u003eThe attacker creates a malicious, unsigned DLL on the compromised system in a non-standard directory like \u003ccode\u003eC:\\ProgramData\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the Windows Registry to configure a service hosted by \u003ccode\u003esvchost.exe\u003c/code\u003e to load the malicious DLL. This often involves manipulating service dependencies or service parameters.\u003c/li\u003e\n\u003cli\u003eThe system is restarted, or the targeted service is manually restarted, causing \u003ccode\u003esvchost.exe\u003c/code\u003e to load the specified DLL.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esvchost.exe\u003c/code\u003e executes the code within the malicious DLL, now running with the privileges of the hosted service (typically SYSTEM).\u003c/li\u003e\n\u003cli\u003eThe malicious DLL performs actions such as installing backdoors, escalating privileges further, or establishing command and control (C2) communication.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the established C2 channel to remotely control the compromised system, exfiltrate data, or perform other malicious activities.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the system by ensuring the malicious DLL is loaded each time the service or system starts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003esvchost.exe\u003c/code\u003e as a host for malicious DLLs makes detection more difficult, allowing attackers to operate undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule to detect unsigned DLLs loaded by \u003ccode\u003esvchost.exe\u003c/code\u003e, focusing on the specified file paths and code signature status.\u003c/li\u003e\n\u003cli\u003eExamine \u003ccode\u003edll.Ext.relative_file_creation_time\u003c/code\u003e to identify DLLs created shortly before being loaded to catch newly created malicious files.\u003c/li\u003e\n\u003cli\u003eReview and validate the legitimacy of all DLLs loaded by \u003ccode\u003esvchost.exe\u003c/code\u003e, focusing on those located in unusual paths.\u003c/li\u003e\n\u003cli\u003eUpdate endpoint detection and response (EDR) systems to specifically monitor for the loading of unsigned DLLs by system processes like \u003ccode\u003esvchost.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eContinuously update the exclusion list of known good DLL hashes to reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:30:00Z","date_published":"2024-01-09T18:30:00Z","id":"/briefs/2024-01-unsigned-dll-svchost/","summary":"Adversaries may load unsigned DLLs into svchost.exe to establish persistence or escalate privileges, leveraging a shared Windows service to execute malicious code with elevated permissions.","title":"Unsigned DLL Loaded by Svchost for Persistence and Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-unsigned-dll-svchost/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["low"],"_cs_tags":["persistence","execution","command-and-control","web shell","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule focuses on identifying potentially malicious activity stemming from Linux-based web servers. The rule is triggered when a web server process, such as Apache, Nginx, or others, initiates an outbound network connection to a destination port that is considered non-standard. This activity can signal the presence of a web shell, a malicious script uploaded to a web server to enable remote access and control. Attackers may exploit compromised web servers to establish covert communication channels, exfiltrate data, or launch further attacks on internal systems. The rule leverages data from Elastic Defend to monitor network connections and filter out legitimate traffic based on a predefined list of common ports and internal IP ranges.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial 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).\u003c/li\u003e\n\u003cli\u003eA web shell is uploaded to the compromised web server, often disguised as a legitimate file or hidden within existing directories.\u003c/li\u003e\n\u003cli\u003eThe attacker interacts with the web shell through HTTP requests, using it as a command and control interface.\u003c/li\u003e\n\u003cli\u003eThe web shell executes commands on the server, initiating outbound network connections to non-standard ports.\u003c/li\u003e\n\u003cli\u003eThese connections may be used to communicate with external C2 servers, download additional payloads, or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the web shell to move laterally within the network, targeting other systems and services.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish persistence on the compromised server, ensuring continued access even after system reboots.\u003c/li\u003e\n\u003cli\u003eThe final objective is data theft, system compromise, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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\u0026rsquo;s ability to move laterally. Organizations in all sectors that rely on web-based applications are potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect web server processes initiating connections to unusual destination ports and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Elastic Defend integration to collect the necessary network event data from Linux endpoints to activate the rule.\u003c/li\u003e\n\u003cli\u003eReview and customize the list of excluded destination ports and internal IP ranges in the Sigma rule to match your organization\u0026rsquo;s specific network configuration and legitimate traffic patterns.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:28:00Z","date_published":"2024-01-09T18:28:00Z","id":"/briefs/2024-01-uncommon-web-server-port/","summary":"The rule identifies unusual outbound network connections on non-standard ports originating from web server processes on Linux systems, indicative of potential web shell activity or unauthorized communication.","title":"Uncommon Destination Port Connection by Web Server on Linux","url":"https://feed.craftedsignal.io/briefs/2024-01-uncommon-web-server-port/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized removal of a Conditional Access (CA) policy in Azure Active Directory can significantly weaken an organization\u0026rsquo;s security posture. Conditional Access policies are critical for enforcing multi-factor authentication, device compliance, and other security controls based on user, location, device, and application conditions. When a non-approved actor removes such a policy, it can open the door for privilege escalation, credential access, and persistence by malicious actors. This activity is often performed after an initial compromise to disable security controls and move laterally within the environment. Identifying and responding to such removals promptly is essential to maintain a strong security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial 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.\u003c/li\u003e\n\u003cli\u003ePrivilege 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.\u003c/li\u003e\n\u003cli\u003eDiscovery: 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.\u003c/li\u003e\n\u003cli\u003eDefense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.\u003c/li\u003e\n\u003cli\u003ePolicy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a \u0026ldquo;Delete conditional access policy\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eCredential 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.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the \u0026ldquo;Delete conditional access policy\u0026rdquo; event in Azure audit logs, indicating a CA policy removal.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eReview and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-azure-ca-policy-removal/","summary":"An unauthorized actor removes a Conditional Access policy in Azure, potentially weakening the organization's security posture and enabling privilege escalation or credential access.","title":"Unauthorized Removal of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-01-09-azure-ca-policy-removal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","SentinelOne Cloud Funnel","Elastic Defend","CCleaner","ManageEngine UEMS Agent","ManageEngine DesktopCentral Agent"],"_cs_severities":["medium"],"_cs_tags":["persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","ManageEngine","CCleaner","Elastic","SentinelOne"],"content_html":"\u003cp\u003eAdversaries may abuse scheduled tasks to maintain persistence on a compromised system. This involves creating or modifying scheduled tasks to execute malicious code at specific times or intervals. This activity can be used to ensure that the attacker\u0026rsquo;s code remains active even after a system restart or user logout. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes to flag potential abuse. The rule is designed for data generated by Elastic Defend, but also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a script or program to create a new scheduled job within the \u003ccode\u003eC:\\Windows\\Tasks\\\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eThe scheduled job is configured to execute a malicious payload at a specified time or interval.\u003c/li\u003e\n\u003cli\u003eThe malicious payload could be a script (e.g., PowerShell) or an executable.\u003c/li\u003e\n\u003cli\u003eThe scheduled job executes, triggering the malicious payload.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the system.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon Event ID 11 (File Create) logging to monitor file creation events on Windows systems.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious Scheduled Job Creation\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on scheduled jobs created in the \u003ccode\u003eC:\\Windows\\Tasks\\\u003c/code\u003e directory with a \u0026ldquo;.job\u0026rdquo; extension.\u003c/li\u003e\n\u003cli\u003eReview and update exclusion lists for known legitimate scheduled job creation processes (e.g., CCleaner, ManageEngine) to minimize false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"/briefs/2024-01-09-scheduled-job-persistence/","summary":"This detection rule identifies attempts to establish persistence on Windows systems by creating scheduled jobs in the Windows Tasks directory, excluding known legitimate jobs.","title":"Persistence via Scheduled Job Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-09-scheduled-job-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","privilege-escalation","masquerading"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies suspicious child processes spawned by WerFault.exe, the Windows Error Reporting tool. Attackers can abuse WerFault by manipulating the \u003ccode\u003eSilentProcessExit\u003c/code\u003e registry key to execute malicious processes. This technique allows for defense evasion, persistence, and privilege escalation. The detection focuses on WerFault processes with specific command-line arguments (\u003ccode\u003e-s\u003c/code\u003e, \u003ccode\u003e-t\u003c/code\u003e, and \u003ccode\u003e-c\u003c/code\u003e) known to be used in SilentProcessExit exploitation, while excluding legitimate executables like \u003ccode\u003eInitcrypt.exe\u003c/code\u003e and \u003ccode\u003eHeimdal.Guard.exe\u003c/code\u003e. The rule helps defenders identify potential attempts to hijack the error reporting mechanism for malicious purposes. The monitored data sources include Windows Event Logs, Sysmon, Elastic Defend, Microsoft Defender XDR, and SentinelOne.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eSilentProcessExit\u003c/code\u003e registry key to specify a malicious process to be executed when a target application crashes. This involves setting the \u003ccode\u003eReportingMode\u003c/code\u003e and \u003ccode\u003eDebugger\u003c/code\u003e values under the \u003ccode\u003eSilentProcessExit\u003c/code\u003e key for the target application.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers a crash in the target application or waits for a legitimate crash to occur.\u003c/li\u003e\n\u003cli\u003eWerFault.exe is invoked to handle the application crash.\u003c/li\u003e\n\u003cli\u003eDue to the registry modification, WerFault.exe spawns the attacker-controlled process, passing command-line arguments such as \u003ccode\u003e-s\u003c/code\u003e, \u003ccode\u003e-t\u003c/code\u003e, and \u003ccode\u003e-c\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker-controlled process executes with the privileges of WerFault.exe, potentially achieving privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe malicious process performs actions such as injecting code into other processes, establishing persistence, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objectives, such as maintaining persistence, escalating privileges, or evading detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s objectives and the scope of the initial compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture WerFault.exe child processes (Data Source: Sysmon).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;WerFault Child Process Masquerading\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eSilentProcessExit\u003c/code\u003e registry key for unauthorized modifications (registry_set event).\u003c/li\u003e\n\u003cli\u003eInvestigate any WerFault.exe processes with command-line arguments \u003ccode\u003e-s\u003c/code\u003e, \u003ccode\u003e-t\u003c/code\u003e, and \u003ccode\u003e-c\u003c/code\u003e (process_creation event).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-09-werfault-child-process/","summary":"This rule detects suspicious child processes of WerFault.exe, a Windows error reporting tool, indicating potential abuse of the SilentProcessExit registry key to execute malicious processes stealthily for defense evasion, persistence, and privilege escalation.","title":"Suspicious WerFault Child Process Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-09-werfault-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Elastic Endgame","Kaspersky Security for Windows Server","Desktop Central Agent","SAP NW Setup"],"_cs_severities":["medium"],"_cs_tags":["persistence","app-compat","shim","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SAP","Kaspersky","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers can exploit the Windows Application Compatibility Shim functionality to maintain persistence and execute arbitrary code within legitimate Windows processes. This is achieved by installing custom shim databases, which are designed to ensure older applications run smoothly on newer operating systems. By manipulating these databases, attackers can stealthily inject malicious code into trusted processes. The rule detects changes in specific registry paths associated with the installation of these databases, excluding known legitimate processes to minimize false positives. This technique allows for the execution of malicious code without directly modifying the target application\u0026rsquo;s executable, making it difficult to detect with traditional methods.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry to create a new entry for a custom shim database. The registry path targeted is typically under \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker writes a malicious \u003ccode\u003e.sdb\u003c/code\u003e file containing the custom shim database to a location on disk.\u003c/li\u003e\n\u003cli\u003eThe registry entry created points to the malicious \u003ccode\u003e.sdb\u003c/code\u003e file.\u003c/li\u003e\n\u003cli\u003eWhen a targeted application is launched, Windows checks the AppCompatFlags registry keys.\u003c/li\u003e\n\u003cli\u003eThe system loads the malicious shim database specified in the registry.\u003c/li\u003e\n\u003cli\u003eThe malicious code within the shim database is executed in the context of the targeted application.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence, as the malicious shim database is loaded every time the targeted application is run.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Custom Shim Database Installation\u003c/code\u003e to your SIEM to identify suspicious registry modifications related to application shimming.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on processes that are not in the exclusion list.\u003c/li\u003e\n\u003cli\u003eBlock or quarantine any identified malicious \u003ccode\u003e.sdb\u003c/code\u003e files to prevent further execution.\u003c/li\u003e\n\u003cli\u003eReview and update the exclusion list in the Sigma rule with any newly identified legitimate applications that use shim databases, reducing false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-09-app-compat-shim-persistence/","summary":"Attackers abuse the Application Compatibility Shim functionality in Windows to establish persistence and achieve arbitrary code execution by installing malicious shim databases, which this detection identifies through monitoring registry changes.","title":"Detection of Custom Shim Database Installation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-09-app-compat-shim-persistence/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2023-50164"}],"_cs_exploited":false,"_cs_products":["Struts 2"],"_cs_severities":["high"],"_cs_tags":["apache-struts","webshell","cve-2023-50164","initial-access","persistence","command-and-control"],"_cs_type":"advisory","_cs_vendors":["Apache"],"content_html":"\u003cp\u003eCVE-2023-50164 is a critical path traversal vulnerability affecting Apache Struts 2 versions prior to 2.5.33 or 6.3.0.2. The vulnerability resides in the file upload functionality, allowing attackers to manipulate file upload parameters and write malicious files, such as JSP web shells, to arbitrary locations on the web server. Successful exploitation leads to remote code execution. Detection focuses on correlating suspicious file upload requests to Struts endpoints with subsequent creation of JSP files in web-accessible directories, indicating successful exploitation. The attack involves crafting malicious multipart/form-data POST requests with WebKitFormBoundary to Struts .action upload endpoints.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a malicious HTTP POST request to a vulnerable Apache Struts endpoint (e.g., \u003ccode\u003e*.action\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe HTTP POST request contains a \u003ccode\u003emultipart/form-data\u003c/code\u003e content type with a \u003ccode\u003eWebKitFormBoundary\u003c/code\u003e string.\u003c/li\u003e\n\u003cli\u003eThe request exploits CVE-2023-50164, leveraging a path traversal vulnerability in the file upload process.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses security controls due to the path traversal vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads a malicious JSP file (web shell) to a web-accessible directory, such as Tomcat\u0026rsquo;s \u003ccode\u003ewebapps\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eA Java process (e.g., Tomcat) creates the JSP web shell file in the webapps directory.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the deployed web shell via HTTP.\u003c/li\u003e\n\u003cli\u003eThe attacker executes arbitrary commands on the server through the web shell.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Apache Struts CVE-2023-50164 Webshell Creation\u0026rdquo; to detect JSP file creation events in webapps directories following suspicious POST requests as described in the overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Apache Struts CVE-2023-50164 Suspicious POST Request\u0026rdquo; to detect suspicious POST requests to Struts endpoints with \u003ccode\u003emultipart/form-data\u003c/code\u003e content containing \u003ccode\u003eWebKitFormBoundary\u003c/code\u003e, as indicated in the Attack Chain.\u003c/li\u003e\n\u003cli\u003ePatch 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.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-05T18:22:00Z","date_published":"2024-01-05T18:22:00Z","id":"/briefs/2024-01-apache-struts-cve-2023-50164-webshell/","summary":"Exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2, is detected by identifying malicious multipart/form-data POST requests with WebKitFormBoundary targeting Struts .action upload endpoints, followed by JSP web shell creation in Tomcat's webapps directories, indicating remote code execution.","title":"Apache Struts CVE-2023-50164 Exploitation Leading to Web Shell Deployment","url":"https://feed.craftedsignal.io/briefs/2024-01-apache-struts-cve-2023-50164-webshell/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub"],"_cs_severities":["low"],"_cs_tags":["github","repository","archive","unarchive","persistence","impact","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of unauthorized changes to GitHub repository archive status. Attackers may archive or unarchive repositories as a means of persistence, to impact the availability of resources, or to impair defenses by hiding malicious code. The activity is logged within GitHub\u0026rsquo;s audit logs and can be monitored to identify potentially malicious actions. Monitoring these events can help organizations identify and respond to unauthorized modifications of their GitHub repositories. This is especially relevant for organizations relying heavily on GitHub for code management and collaboration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub account with repository administration privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings page of a target repository.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the repository\u0026rsquo;s archive status, either archiving or unarchiving it depending on their objective.\u003c/li\u003e\n\u003cli\u003eGitHub logs the \u0026lsquo;repo.archived\u0026rsquo; or \u0026lsquo;repo.unarchived\u0026rsquo; action in the organization\u0026rsquo;s audit logs.\u003c/li\u003e\n\u003cli\u003e(If archiving) Legitimate users may lose access to the repository and its code, causing disruption.\u003c/li\u003e\n\u003cli\u003e(If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to exploit the unarchived repository for further malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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\u0026rsquo;s access and objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GitHub Repository Archive Status Changed\u0026rdquo; to your SIEM and tune for your environment. This rule detects the \u003ccode\u003erepo.archived\u003c/code\u003e and \u003ccode\u003erepo.unarchived\u003c/code\u003e actions in GitHub audit logs (logsource: github, service: audit).\u003c/li\u003e\n\u003cli\u003eReview GitHub audit logs regularly for unexpected repository archiving or unarchiving events.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events to determine if the actions were authorized.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T15:00:00Z","date_published":"2024-01-04T15:00:00Z","id":"/briefs/2024-01-github-repo-archive-status-changed/","summary":"Detection of GitHub repository archiving or unarchiving events, which could indicate malicious activity such as persistence, impact, or defense impairment.","title":"GitHub Repository Archive Status Changed","url":"https://feed.craftedsignal.io/briefs/2024-01-github-repo-archive-status-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Outlook"],"_cs_severities":["medium"],"_cs_tags":["persistence","vba","outlook","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers can leverage Microsoft Outlook\u0026rsquo;s VBA scripting capabilities to establish persistence on compromised systems. This is achieved by installing malicious VBA templates within the Outlook environment. These templates are designed to execute upon application startup, granting the attacker sustained access and control. The attack centers around unauthorized modifications to the \u003ccode\u003eVbaProject.OTM\u003c/code\u003e file, a critical component for VBA script storage in Outlook. This technique allows threat actors to maintain a foothold even after system restarts or user logoffs. Defenders need to monitor for suspicious changes to this file to identify and mitigate potential compromises.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the target system, potentially through phishing or other social engineering methods (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a user with Microsoft Outlook installed and running on a Windows system.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or replaces the existing \u003ccode\u003eVbaProject.OTM\u003c/code\u003e file located in the user\u0026rsquo;s Outlook profile (\u003ccode\u003eC:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe modified \u003ccode\u003eVbaProject.OTM\u003c/code\u003e file contains malicious VBA code designed to execute when Outlook starts.\u003c/li\u003e\n\u003cli\u003eThe victim launches Microsoft Outlook.\u003c/li\u003e\n\u003cli\u003eThe malicious VBA code within \u003ccode\u003eVbaProject.OTM\u003c/code\u003e executes automatically upon Outlook startup, establishing persistence.\u003c/li\u003e\n\u003cli\u003eThe VBA script can perform various malicious actions, such as downloading and executing additional payloads, establishing command and control, or exfiltrating data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives and scope of the campaign. If the attack succeeds, an attacker could gain complete control over the user\u0026rsquo;s email account and associated data, leading to significant data breaches and financial losses.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Outlook VBA Template Modification\u003c/code\u003e to your SIEM to identify unauthorized modifications to the \u003ccode\u003eVbaProject.OTM\u003c/code\u003e file based on file creation events.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon file creation logging (Event ID 11) to activate the \u003ccode\u003eDetect Outlook VBA Template Modification\u003c/code\u003e rule.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict unauthorized modifications to Outlook VBA files as described in the \u0026ldquo;Response and remediation\u0026rdquo; section of the source.\u003c/li\u003e\n\u003cli\u003eMonitor file creation events related to \u003ccode\u003eVbaProject.OTM\u003c/code\u003e in the specified paths (\u003ccode\u003eC:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Outlook\\\\VbaProject.OTM\u003c/code\u003e) as highlighted in the rule query.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T12:00:00Z","date_published":"2024-01-04T12:00:00Z","id":"/briefs/2024-01-outlook-vba-persistence/","summary":"Attackers establish persistence by installing a malicious VBA template in Microsoft Outlook, triggering scripts upon application startup by modifying the VBAProject.OTM file, detected by monitoring for unauthorized file modifications.","title":"Persistence via Malicious Microsoft Outlook VBA Template","url":"https://feed.craftedsignal.io/briefs/2024-01-outlook-vba-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule focuses on identifying suspicious activities related to Kubernetes Role-Based Access Control (RBAC). It specifically targets the creation, update, or patching of Kubernetes Roles or ClusterRoles that introduce high-risk permissions. These include wildcard access, where a single rule grants access to all resources, and escalation verbs like \u0026lsquo;bind\u0026rsquo;, \u0026rsquo;escalate\u0026rsquo;, or \u0026lsquo;impersonate\u0026rsquo;, which can be used to elevate privileges. The rule is designed to alert security teams to potential privilege escalation or unauthorized access attempts within Kubernetes environments. The Elastic detection rule was last updated on April 27, 2026, and aims to detect malicious actors attempting to gain cluster-admin-equivalent access by creating new ClusterRoles with \u003ccode\u003e*\u003c/code\u003e verbs/resources and binding them to their accounts or service accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create or modify a Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker adds high-risk permissions to the Role or ClusterRole, such as wildcard verbs/resources (\u003ccode\u003e*\u003c/code\u003e) or escalation verbs (bind, escalate, impersonate).\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server authorizes the request, potentially due to misconfigured RBAC policies.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies a RoleBinding or ClusterRoleBinding to associate the modified Role or ClusterRole with a target user, group, or service account.\u003c/li\u003e\n\u003cli\u003eThe target user, group, or service account now possesses the elevated privileges granted by the modified Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform unauthorized actions within the cluster, such as accessing sensitive data or deploying malicious workloads.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by maintaining the modified Role or ClusterRole and its associated bindings, allowing continued access to elevated privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Creation of Sensitive Role\u003c/code\u003e to your SIEM to detect the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions.\u003c/li\u003e\n\u003cli\u003eEnable Kubernetes audit logging to capture the necessary events for the Sigma rules to function effectively (reference: Kubernetes audit logs in \u003ccode\u003elogsource\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement 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).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit RBAC configurations to identify and remediate overly permissive roles and bindings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T12:00:00Z","date_published":"2024-01-04T12:00:00Z","id":"/briefs/2024-01-kubernetes-sensitive-role-creation/","summary":"Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs, potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-sensitive-role-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","bitlocker","key-retrieval","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers with access to Azure Active Directory, either through compromised credentials or an insider threat, can retrieve BitLocker recovery keys stored within the Azure environment. This allows them to decrypt volumes protected with BitLocker encryption. While retrieving BitLocker keys is a legitimate administrative function, anomalous or unauthorized access can indicate malicious activity. Attackers may leverage this to gain unauthorized access to encrypted data, escalate privileges, or move laterally within the compromised environment. Defenders need to monitor BitLocker key retrieval events for unusual patterns or unauthorized access attempts to detect and prevent potential data breaches or other malicious activities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains unauthorized access to an Azure Active Directory account with sufficient privileges, possibly via credential phishing or password spraying (T1078.004).\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation (if needed): The attacker escalates privileges within Azure AD if the initially compromised account lacks the necessary permissions to read BitLocker keys.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker uses Azure AD tools or PowerShell cmdlets to identify devices with BitLocker encryption enabled.\u003c/li\u003e\n\u003cli\u003eKey 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.\u003c/li\u003e\n\u003cli\u003eOffline Access: The attacker uses the retrieved BitLocker recovery key to unlock the encrypted drive on a compromised system or a copied disk image.\u003c/li\u003e\n\u003cli\u003eData 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s subsequent actions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect BitLocker key retrieval events in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eReview Azure AD access logs for suspicious activity related to user accounts that have permissions to read BitLocker keys (reference: Sigma rule).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges in Azure AD, to prevent unauthorized access (T1078.004).\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies to restrict access to sensitive Azure resources, including BitLocker recovery keys, based on factors such as location, device, and user risk.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure AD roles and permissions to ensure that users only have the necessary privileges to perform their job functions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:29:00Z","date_published":"2024-01-03T18:29:00Z","id":"/briefs/2024-01-bitlocker-key-retrieval/","summary":"An adversary with sufficient privileges in Azure Active Directory may attempt to retrieve BitLocker keys to decrypt drives for lateral movement or data exfiltration.","title":"Azure AD Bitlocker Key Retrieval","url":"https://feed.craftedsignal.io/briefs/2024-01-bitlocker-key-retrieval/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe compromise of privileged accounts within cloud environments is a significant risk. Azure Privileged Identity Management (PIM) is designed to mitigate this risk by enforcing time-bound and approval-based role activation. This brief focuses on the detection of PIM elevation requests that are either approved or denied. While legitimate administrator actions will trigger these events, unexpected or unauthorized approvals/denials, especially those occurring outside of normal business hours or originating from unusual locations, warrant immediate investigation. This activity can indicate attempts at unauthorized privilege escalation, lateral movement, or data exfiltration within the Azure environment. Monitoring these events provides an opportunity to identify and respond to potential breaches before significant damage can occur.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a low-privileged Azure account, possibly through credential phishing or password reuse.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to activate a privileged role (e.g., Global Administrator, Security Administrator) through Azure PIM.\u003c/li\u003e\n\u003cli\u003eThe PIM request triggers an approval workflow, requiring authorization from designated approvers.\u003c/li\u003e\n\u003cli\u003eAn attacker compromises an approver account, enabling them to approve their own malicious PIM request or deny a legitimate one.\u003c/li\u003e\n\u003cli\u003eAlternatively, an unwitting approver approves a malicious request, potentially due to social engineering.\u003c/li\u003e\n\u003cli\u003eUpon approval, the attacker\u0026rsquo;s account is temporarily elevated to the requested privileged role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform malicious actions, such as creating new accounts, modifying security policies, or accessing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to maintain persistence by creating backdoor accounts or modifying access controls, potentially circumventing PIM restrictions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure PIM Elevation Approved or Denied\u003c/code\u003e to your SIEM to detect unusual PIM activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any PIM approval or denial events occurring outside of normal business hours or originating from unexpected locations, focusing on the \u003ccode\u003eproperties.message\u003c/code\u003e field in the logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts, especially those with approval permissions for PIM requests.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit PIM role assignments and approval workflows to ensure they align with the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eEnable alerting on changes to PIM policies and configurations to detect any unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for suspicious activity following PIM role activation, looking for actions associated with common attack techniques (e.g., account creation, policy modification).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:27:00Z","date_published":"2024-01-03T18:27:00Z","id":"/briefs/2024-01-azure-pim-elevation/","summary":"Detection of Azure Privileged Identity Management (PIM) elevation approvals or denials, which, if unexpected, may indicate unauthorized privilege escalation or malicious activity within an Azure environment.","title":"Azure PIM Elevation Approved or Denied","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azuread","role-assignment","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers often target identity and access management systems like Azure Active Directory (Azure AD) to gain control over an organization\u0026rsquo;s resources. By adding users to highly privileged roles such as Global Administrator or Device Administrator, adversaries can achieve persistence, allowing them to regain access even after initial compromises are remediated. This activity often occurs after an initial foothold has been established, enabling privilege escalation and stealthy movement within the cloud environment. Monitoring role assignments in Azure AD is crucial for detecting and preventing unauthorized access and maintaining the integrity of the organization\u0026rsquo;s cloud infrastructure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure AD account, possibly through credential theft or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses PowerShell with compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Azure AD roles and identifies potential targets like Global Administrator or Device Administrator.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAdd-AzureADGroupMember\u003c/code\u003e or similar cmdlets to add a compromised or newly created user account to the target role.\u003c/li\u003e\n\u003cli\u003eThe Azure AD audit logs record the \u0026ldquo;Add member to role\u0026rdquo; operation with the specific role GUIDs (e.g., \u0026lsquo;7698a772-787b-4ac8-901f-60d6b08affd2\u0026rsquo; or \u0026lsquo;62e90394-69f5-4237-9190-012177145e10\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003eThe newly added user account inherits the privileges associated with the Global Administrator or Device Administrator role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive data, modify configurations, or deploy malicious applications.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistent access by creating new administrative accounts or modifying existing ones to maintain control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious additions of users to Global or Device Admin roles in Azure AD Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of credential theft (T1078.004).\u003c/li\u003e\n\u003cli\u003eRegularly review Azure AD role assignments to identify and remove any unauthorized or unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eMonitor for other suspicious Azure AD activity, such as unusual sign-in patterns, application registrations, and resource deployments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:27:00Z","date_published":"2024-01-03T18:27:00Z","id":"/briefs/2024-01-03-azuread-role-assignment/","summary":"An attacker may attempt to add a user to a high-privilege Azure AD role, such as Global Administrator or Device Administrator, to establish persistence, gain initial access, escalate privileges, or operate stealthily within the compromised environment.","title":"Azure AD User Added to Global or Device Admin Role","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azuread-role-assignment/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS STS"],"_cs_severities":["medium"],"_cs_tags":["aws","saml","cloudtrail","initial-access","lateral-movement","persistence","privilege-escalation","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e and \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or creates a malicious SAML identity provider.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the AWS environment to trust the malicious SAML provider using \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a SAML assertion to assume a specific role within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e API call to authenticate with AWS using the crafted SAML assertion.\u003c/li\u003e\n\u003cli\u003eAWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events to detect suspicious role assumptions (see \u0026ldquo;AssumeRoleWithSAML Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events to detect unauthorized SAML provider modifications (see \u0026ldquo;UpdateSAMLProvider Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.\u003c/li\u003e\n\u003cli\u003eTune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:30Z","date_published":"2024-01-03T18:22:30Z","id":"/briefs/2024-01-03-aws-suspicious-saml/","summary":"This rule identifies suspicious SAML activity in AWS, such as AssumeRoleWithSAML and UpdateSAMLProvider events, which could indicate an attacker gaining backdoor access, escalating privileges, or establishing persistence.","title":"Suspicious AWS SAML Activity Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-suspicious-saml/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Outlook"],"_cs_severities":["medium"],"_cs_tags":["persistence","registry_modification","outlook","email"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers are known to modify Outlook security settings by directly manipulating registry values. This tactic allows them to bypass built-in security controls and enable potentially malicious functionalities such as running unsafe mail client rules. This circumvention of security measures can be leveraged for various malicious purposes, including persistence, data exfiltration, and further compromise of the victim\u0026rsquo;s system. The specific registry keys targeted reside under \u003ccode\u003e\\SOFTWARE\\Microsoft\\Office\\Outlook\\Security\\\u003c/code\u003e. This technique has been observed in various attack scenarios and poses a significant risk to organizations relying on Outlook for email communication. The modification of these registry settings may be performed by various means, ranging from manually executed commands to automated scripts deployed as part of a larger attack campaign.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system through methods such as phishing or exploiting vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the specific registry keys controlling Outlook security settings, located under \u003ccode\u003e\\SOFTWARE\\Microsoft\\Office\\Outlook\\Security\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a command-line tool or script (e.g., \u003ccode\u003ereg.exe\u003c/code\u003e, PowerShell) to modify the registry values related to Outlook security settings.\u003c/li\u003e\n\u003cli\u003eSpecifically, values are modified to enable the execution of \u0026ldquo;unsafe\u0026rdquo; mail client rules, potentially allowing arbitrary code execution via crafted emails.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious email designed to trigger the newly enabled, unsafe mail rules.\u003c/li\u003e\n\u003cli\u003eUpon receiving the email, Outlook processes the rules, executing the attacker\u0026rsquo;s payload.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves code execution, enabling further malicious activities, such as data exfiltration or lateral movement within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives, potentially affecting all users within an organization if the attacker gains domain administrator access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Outlook Security Settings Updated - Registry\u0026rdquo; to your SIEM to detect unauthorized modifications to Outlook security-related registry keys (logsource: registry_set/windows).\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for suspicious processes (e.g., \u003ccode\u003ereg.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e) modifying registry keys under \u003ccode\u003e\\SOFTWARE\\Microsoft\\Office\\Outlook\\Security\\\u003c/code\u003e (Sigma rule below, logsource: process_creation/windows).\u003c/li\u003e\n\u003cli\u003eImplement strict application control policies to prevent unauthorized execution of scripts and executables that could be used to modify registry settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:15:00Z","date_published":"2024-01-03T18:15:00Z","id":"/briefs/2024-01-outlook-registry-security-settings/","summary":"Attackers modify Outlook security settings via registry changes to enable malicious mail rules and bypass security controls, potentially leading to persistence and data compromise.","title":"Outlook Security Settings Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-outlook-registry-security-settings/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["persistence","execution","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies suspicious program executions initiated by scheduled tasks on Windows systems. Adversaries often exploit scheduled tasks for persistence and to execute malicious programs. This rule focuses on detecting known malicious executables, such as PowerShell, Cmd, and MSHTA, when launched from unusual file paths like user directories or temporary folders. It leverages process lineage analysis, specifically looking for processes spawned by \u003ccode\u003esvchost.exe\u003c/code\u003e with the \u0026ldquo;Schedule\u0026rdquo; argument, to determine if the execution originated from a scheduled task. The rule aims to pinpoint potential threats effectively by excluding benign processes and focusing on suspicious combinations of executables and paths. The rule was last updated on 2026-05-04.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies a scheduled task to execute a malicious payload. This task is designed to run at a specific time or event.\u003c/li\u003e\n\u003cli\u003eThe Windows Task Scheduler service (\u003ccode\u003esvchost.exe\u003c/code\u003e with \u0026ldquo;Schedule\u0026rdquo; argument) initiates the scheduled task.\u003c/li\u003e\n\u003cli\u003eThe scheduled task executes a suspicious executable, such as \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ecmd.exe\u003c/code\u003e, or \u003ccode\u003emshta.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe suspicious executable is launched from an unusual or suspicious path, such as \u003ccode\u003eC:\\\\Users\\\\\u003c/code\u003e, \u003ccode\u003eC:\\\\ProgramData\\\\\u003c/code\u003e, or \u003ccode\u003eC:\\\\Windows\\\\Temp\\\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe executed payload performs malicious activities, such as downloading additional malware, establishing persistence, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the system through the scheduled task, allowing for repeated execution of the malicious payload.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging with command line arguments to detect suspicious executions (logs-endpoint.events.process-* and logs-windows.sysmon_operational-*).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Execution via Scheduled Task\u0026rdquo; 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).\u003c/li\u003e\n\u003cli\u003eInvestigate 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).\u003c/li\u003e\n\u003cli\u003eMonitor scheduled tasks for unauthorized modifications or additions, as this is a common technique for persistence (registry_set).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:00:00Z","date_published":"2024-01-03T18:00:00Z","id":"/briefs/2024-01-suspicious-scheduled-task-runtime/","summary":"This rule identifies execution of suspicious programs via scheduled tasks by looking at process lineage and command line usage, detecting processes such as cscript.exe, powershell.exe, and cmd.exe when executed from suspicious paths like C:\\Users\\ and C:\\ProgramData\\.","title":"Suspicious Execution via Scheduled Task","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-scheduled-task-runtime/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["high"],"_cs_tags":["credential-access","persistence","windows","active-directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe SeEnableDelegationPrivilege user right, when assigned to a security principal, allows that principal to be trusted for delegation within Active Directory. Attackers can abuse this right to compromise accounts and elevate privileges by impersonating other users or services. This technique can be used for lateral movement, persistence, and ultimately, domain dominance. Defenders should monitor for the assignment of this privilege, especially to accounts that should not have it. The targeted behavior is logged as event ID 4704 in Windows Security logs. This activity is critical to monitor as it represents a powerful tool for attackers to move laterally and maintain persistence within a compromised environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised account with sufficient privileges to modify user rights.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the SeEnableDelegationPrivilege to a target account using tools like \u003ccode\u003entrights.exe\u003c/code\u003e or PowerShell cmdlets.\u003c/li\u003e\n\u003cli\u003eWindows Security Event 4704 is generated, logging the privilege assignment.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the target account\u0026rsquo;s attributes, such as \u003ccode\u003euserAccountControl\u003c/code\u003e or \u003ccode\u003emsDS-AllowedToDelegateTo\u003c/code\u003e, to enable delegation.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages Kerberos delegation to impersonate other users or services.\u003c/li\u003e\n\u003cli\u003eUsing the impersonated credentials, the attacker accesses sensitive resources or performs privileged actions.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network, compromising additional systems and accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration or domain dominance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Authorization Policy Change\u0026rdquo; to generate Windows Security Event ID 4704 (Setup instructions: \u003ca href=\"https://ela.st/audit-authorization-policy-change)\"\u003ehttps://ela.st/audit-authorization-policy-change)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal\u0026rdquo; to your SIEM to detect the assignment of this privilege.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where SeEnableDelegationPrivilege is assigned, focusing on the targeted account and the source of the change.\u003c/li\u003e\n\u003cli\u003eMonitor for modifications to delegation-related attributes on user and computer objects.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:23:00Z","date_published":"2024-01-03T17:23:00Z","id":"/briefs/2024-01-se-enable-delegation/","summary":"Detection of the assignment of the SeEnableDelegationPrivilege user right to a principal can indicate potential Active Directory compromise and privilege elevation by attackers.","title":"SeEnableDelegationPrivilege Assignment Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-se-enable-delegation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","admission-controller","persistence","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubernetes Admission Controllers are critical components that intercept and potentially modify requests to the Kubernetes API server. These controllers rely on admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) deployed within the cluster. A malicious actor can abuse these webhooks to establish persistence by modifying pod creation operations and injecting malicious containers into new pods via MutatingAdmissionWebhook. Alternatively, ValidatingAdmissionWebhook can be used to intercept API server requests, potentially exposing secrets and sensitive information. This activity allows for credential access and privilege escalation, impacting the overall security posture of the Kubernetes cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.\u003c/li\u003e\n\u003cli\u003eThe malicious webhook is deployed to the cluster, configured to modify pod specifications.\u003c/li\u003e\n\u003cli\u003eWhen new pods are created, the webhook injects a malicious container into the pod specification before deployment.\u003c/li\u003e\n\u003cli\u003eThe malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.\u003c/li\u003e\n\u003cli\u003eThe webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Kubernetes Admission Controller Configuration Change\u0026rdquo; to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e and \u003ccode\u003eMICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e operations to identify potential abuse.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-azure-kubernetes-admission-controller/","summary":"An adversary can exploit Kubernetes Admission Controllers in Azure to achieve persistence, privilege escalation, or credential access by manipulating webhook configurations.","title":"Malicious Azure Kubernetes Admission Controller Configuration","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azuread","temporary-access-pass","privilege-escalation","initial-access","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies when a temporary access pass (TAP) is added to an Azure Active Directory (Azure AD) account. TAPs are intended for temporary use, allowing users to access resources or perform actions without needing a password. While legitimate use cases exist, adversaries can leverage TAPs to gain unauthorized access, escalate privileges, establish persistence, or move laterally within an Azure environment. This activity warrants investigation, especially if the TAP is added to a privileged account. The source material does not indicate a specific campaign or threat actor, but the technique aligns with common cloud-based attack vectors.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise (Optional):\u003c/strong\u003e An attacker gains initial access to an Azure AD account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e The attacker escalates privileges to an account with sufficient permissions to manage TAPs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTAP Generation:\u003c/strong\u003e The attacker, using an account with appropriate permissions, generates a temporary access pass (TAP) for a target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTAP Activation:\u003c/strong\u003e The attacker uses the TAP to authenticate to the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Access:\u003c/strong\u003e Once authenticated, the attacker gains access to resources and applications associated with the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker uses the compromised account to access other resources or accounts within the environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Optional):\u003c/strong\u003e The attacker establishes persistence by creating new credentials or modifying existing ones, if permissions allow.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect TAP additions in Azure AD audit logs (see rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where TAPs are added to privileged accounts in Azure AD, as highlighted in the rule description and references.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for suspicious activity surrounding the TAP generation event, including the source IP address and user agent (see rules).\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous sign-in activity using TAPs, specifically focusing on unusual locations or devices.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-azure-tap-added/","summary":"Detection of a temporary access pass (TAP) being added to an Azure AD account, which could indicate potential privilege escalation, initial access, persistence, or stealth activity.","title":"Azure AD Temporary Access Pass Added to Account","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-tap-added/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["medium"],"_cs_tags":["time-based-evasion","malware","persistence","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Splunk"],"content_html":"\u003cp\u003eThis brief focuses on the detection of \u003ccode\u003echoice.exe\u003c/code\u003e being used within batch files as a time-delay tactic, a technique notably employed by the SnakeKeylogger malware. The analysis leverages data from Endpoint Detection and Response (EDR) agents, scrutinizing process names and command-line executions. This behavior is significant because it suggests the implementation of time-based evasion techniques designed to circumvent detection mechanisms. Successful evasion could enable attackers to execute malicious code covertly, remove incriminating files, and establish persistent access on compromised systems. The use of \u003ccode\u003echoice.exe\u003c/code\u003e for such purposes warrants immediate investigation by security operations center (SOC) analysts due to the potential for significant system compromise and data exfiltration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access via an unknown vector.\u003c/li\u003e\n\u003cli\u003eA batch script is executed on the target system.\u003c/li\u003e\n\u003cli\u003eThe batch script uses \u003ccode\u003echoice.exe\u003c/code\u003e with the \u003ccode\u003e/T\u003c/code\u003e and \u003ccode\u003e/N\u003c/code\u003e parameters to introduce a time delay. The \u003ccode\u003e/T\u003c/code\u003e parameter specifies a timeout period, and the \u003ccode\u003e/N\u003c/code\u003e parameter suppresses the display of choices.\u003c/li\u003e\n\u003cli\u003eThis delay allows the malware to evade time-sensitive detection mechanisms.\u003c/li\u003e\n\u003cli\u003eAfter the delay, the script executes further commands, potentially downloading and executing a payload.\u003c/li\u003e\n\u003cli\u003eThe payload executes, installing a keylogger such as SnakeKeylogger or 0bj3ctivity Stealer.\u003c/li\u003e\n\u003cli\u003eThe keylogger captures sensitive information such as keystrokes and clipboard data.\u003c/li\u003e\n\u003cli\u003eThe stolen data is exfiltrated to a remote server.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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\u0026rsquo;s objectives and the compromised systems\u0026rsquo; value.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Choice.exe Time Delay\u003c/code\u003e to your SIEM to detect the use of \u003ccode\u003echoice.exe\u003c/code\u003e with time-delay parameters (log source: \u003ccode\u003eprocess_creation\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging (Event ID 1) to capture the necessary process execution data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003echoice.exe\u003c/code\u003e being used with the \u003ccode\u003e/T\u003c/code\u003e and \u003ccode\u003e/N\u003c/code\u003e parameters to determine if it is part of a malicious script.\u003c/li\u003e\n\u003cli\u003eBlock the execution of unsigned or untrusted batch scripts to prevent the initial execution of the malicious code.\u003c/li\u003e\n\u003cli\u003eMonitor endpoint activity for suspicious processes and network connections originating from systems where \u003ccode\u003echoice.exe\u003c/code\u003e has been detected.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-time-based-evasion-choice/","summary":"Detection of choice.exe used in batch files for time-based evasion, a technique observed in SnakeKeylogger malware, indicating potential stealthy code execution and persistence.","title":"Windows Time-Based Evasion via Choice Exec","url":"https://feed.craftedsignal.io/briefs/2024-01-time-based-evasion-choice/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["file-integrity","privilege-escalation","persistence","linux"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers often target sensitive and critical files on Linux systems to maintain persistence, escalate privileges, or disrupt system operations. These files include system configuration files, authentication files, and critical application files. Monitoring changes to these files is crucial for detecting malicious activity. This brief focuses on identifying suspicious process executions that could indicate unauthorized modification of sensitive files. The detection strategy covers processes…\u003c/p\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-sensitive-file-modification/","summary":"This threat brief covers the detection of suspicious processes modifying sensitive files on Linux systems, potentially indicating malicious attempts to persist, escalate privileges, or disrupt system operations.","title":"Suspicious Modification of Sensitive Linux Files","url":"https://feed.craftedsignal.io/briefs/2024-01-sensitive-file-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["persistence","windows","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis rule detects a common persistence technique where attackers configure malicious scripts or programs to run automatically after a user logs on to a Windows system. The technique abuses the Registry Run keys and Startup folders to achieve persistence. The rule specifically identifies processes launched shortly after the userinit.exe and explorer.exe processes start, focusing on processes known to be used for malicious purposes, such as cscript.exe, wscript.exe, PowerShell.exe, MSHTA.exe, RUNDLL32.exe, REGSVR32.exe, RegAsm.exe, MSBuild.exe, and InstallUtil.exe. Additionally, it checks if these processes are launched from or access suspicious paths like C:\\Users*, C:\\ProgramData*, and C:\\Windows\\Temp*. This detection is crucial because it helps identify potentially malicious activities that bypass standard security measures by leveraging legitimate system tools.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system, typically through phishing, exploiting vulnerabilities, or using stolen credentials (not covered in the source).\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe system starts, and the winlogon.exe process initiates userinit.exe.\u003c/li\u003e\n\u003cli\u003euserinit.exe starts explorer.exe, loading the user\u0026rsquo;s profile and desktop environment.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003ecscript.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, or \u003ccode\u003erundll32.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe malicious process executes from a suspicious location, such as \u003ccode\u003eC:\\\\Users\\\\*\u003c/code\u003e, \u003ccode\u003eC:\\\\ProgramData\\\\*\u003c/code\u003e, or \u003ccode\u003eC:\\\\Windows\\\\Temp\\\\*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe malicious process performs its intended actions, such as downloading additional malware, establishing command and control, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe system remains infected, with the malicious process running every time the user logs on, ensuring persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Persistent Suspicious Program Execution\u0026rdquo; to detect suspicious processes executed shortly after user logon (rule).\u003c/li\u003e\n\u003cli\u003eEnable process creation logging via Sysmon or Elastic Defend to provide the data required for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the process lineage and command-line arguments of the suspicious processes.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and regularly audit user accounts to prevent unauthorized modifications to the Registry Run keys.\u003c/li\u003e\n\u003cli\u003eBlock execution of the listed suspicious processes (\u003ccode\u003ecscript.exe\u003c/code\u003e, \u003ccode\u003ewscript.exe\u003c/code\u003e, \u003ccode\u003ePowerShell.EXE\u003c/code\u003e, \u003ccode\u003eMSHTA.EXE\u003c/code\u003e, \u003ccode\u003eRUNDLL32.EXE\u003c/code\u003e, \u003ccode\u003eREGSVR32.EXE\u003c/code\u003e, \u003ccode\u003eRegAsm.exe\u003c/code\u003e, \u003ccode\u003eMSBuild.exe\u003c/code\u003e, \u003ccode\u003eInstallUtil.exe\u003c/code\u003e) from suspicious paths (\u003ccode\u003eC:\\\\Users\\\\*\u003c/code\u003e, \u003ccode\u003eC:\\\\ProgramData\\\\*\u003c/code\u003e, \u003ccode\u003eC:\\\\Windows\\\\Temp\\\\*\u003c/code\u003e) via application control policies (overview).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-susp-proc-startup/","summary":"This analytic identifies suspicious programs such as script interpreters, rundll32, or MSBuild being executed shortly after user logon, indicating potential persistence mechanisms abusing the registry run keys.","title":"Execution of Persistent Suspicious Programs via Run Keys","url":"https://feed.craftedsignal.io/briefs/2024-01-03-susp-proc-startup/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","password-reset","privilege-escalation","initial-access","persistence","credential-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user-initiated password resets within Azure Active Directory (Azure AD). While legitimate password resets are common, monitoring this activity can help identify potentially malicious behavior, such as an attacker attempting to gain unauthorized access to an account or an insider threat actor escalating privileges. Attackers may leverage compromised credentials or social engineering to initiate password resets, bypassing multi-factor authentication (MFA) if it is not properly configured or enforced. This detection is important for defenders because successful password resets can lead to a complete account takeover, allowing attackers to access sensitive data, resources, and systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user\u0026rsquo;s credentials through phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a password reset request using the \u0026ldquo;Forgot password\u0026rdquo; feature or a similar mechanism.\u003c/li\u003e\n\u003cli\u003eAzure AD sends a password reset verification code or link to the user\u0026rsquo;s registered email address or phone number.\u003c/li\u003e\n\u003cli\u003eIf the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the verification code or link to set a new password for the user\u0026rsquo;s Azure AD account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs in to the Azure AD account with the new password, gaining unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePassword Reset By User Account\u003c/code\u003e to your SIEM to detect user-initiated password resets in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected password resets, especially those initiated by users who have not recently requested a password change.\u003c/li\u003e\n\u003cli\u003eReview and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-azure-user-password-reset/","summary":"Detects when a user successfully resets their own password in Azure Active Directory, which may indicate malicious activity or account compromise.","title":"Azure AD User Password Reset Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-user-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Splunk"],"content_html":"\u003cp\u003eThis threat brief focuses on the abuse of the native Windows utility \u003ccode\u003eattrib.exe\u003c/code\u003e to hide files and directories. Attackers use this technique to conceal malicious payloads, tools, or command-and-control infrastructure from both users and security software. By setting the hidden attribute (+h flag), attackers make it more difficult to detect their presence and maintain persistence on compromised systems. This activity is typically observed post-exploitation and can be indicative of more advanced persistent threats. The detection specifically looks for \u003ccode\u003eattrib.exe\u003c/code\u003e command-line arguments including the \u0026ldquo;+h\u0026rdquo; flag. While legitimate uses of \u003ccode\u003eattrib.exe\u003c/code\u003e exist, the use of the \u0026lsquo;+h\u0026rsquo; flag, particularly in sensitive directories, should be investigated.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system, often through phishing, exploiting a vulnerability, or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes arbitrary code on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads or creates malicious files (e.g., backdoors, scripts) on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eattrib.exe\u003c/code\u003e with the \u0026ldquo;+h\u0026rdquo; flag to hide these malicious files and directories, evading detection. Example: \u003ccode\u003eattrib +h C:\\Windows\\Temp\\evil.exe\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eThe attacker may also hide associated log files or other artifacts to further conceal their activities.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence, ensuring continued access even after system reboots.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network, compromising additional systems and escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, which may include data theft, ransomware deployment, or espionage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives and the scope of the compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM to detect suspicious usage of \u003ccode\u003eattrib.exe\u003c/code\u003e with the \u0026lsquo;+h\u0026rsquo; flag.\u003c/li\u003e\n\u003cli\u003eEnable 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).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, paying close attention to the parent processes and the context in which \u003ccode\u003eattrib.exe\u003c/code\u003e is being executed.\u003c/li\u003e\n\u003cli\u003eImplement file integrity monitoring (FIM) on critical system directories to detect unauthorized file modifications, including attribute changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-attrib-hide-files/","summary":"Detection of attrib.exe being used with the +h flag to hide files and directories on Windows systems, a technique used by attackers for defense evasion and persistence.","title":"Attrib.exe Used to Hide Files and Directories","url":"https://feed.craftedsignal.io/briefs/2024-01-attrib-hide-files/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR"],"_cs_severities":["medium"],"_cs_tags":["persistence","startup","windows","attack.persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eAdversaries may abuse the Windows Startup folder to maintain persistence in an environment. The Startup folder is a special folder in Windows where programs added to this folder are executed during account logon without user interaction. This rule identifies script engines (wscript.exe, cscript.exe) creating files or the creation of script files with specific extensions (vbs, vbe, wsh, wsf, js, jse, sct, hta, ps1, bat, cmd) in the Startup folder. The rule is designed for data generated by Elastic Defend and also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a malicious script (e.g., VBScript, PowerShell) designed to execute arbitrary commands.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the Startup folder path for a specific user or all users.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a shortcut file (e.g., .lnk) or a script file directly within the Startup folder.\u003c/li\u003e\n\u003cli\u003eThe shortcut or script is configured to execute the malicious script.\u003c/li\u003e\n\u003cli\u003eThe system is restarted or the user logs in.\u003c/li\u003e\n\u003cli\u003eThe operating system automatically executes the script located in the Startup folder.\u003c/li\u003e\n\u003cli\u003eThe malicious script executes, allowing the attacker to perform actions such as installing malware, establishing persistence, or exfiltrating data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Script Creation in Startup Directory\u0026rdquo; to your SIEM and tune for your environment to identify the creation of suspicious scripts in the Startup folder.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Script Execution via Startup Directory\u0026rdquo; to your SIEM and tune for your environment to identify script execution from the Startup directory.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 11 (File Create) to collect necessary data for the detections above.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by these rules promptly to identify and remediate potential persistence attempts.\u003c/li\u003e\n\u003cli\u003eBlock 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-startup-folder-persistence/","summary":"This rule identifies script engines creating files or the creation of script files in the Windows Startup folder, a persistence technique used by adversaries to automatically execute scripts upon user login.","title":"Suspicious Scripts in the Startup Directory","url":"https://feed.craftedsignal.io/briefs/2024-01-startup-folder-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege-escalation","linux"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers can leverage cron jobs to schedule malicious tasks for persistence, privilege escalation, and execution of arbitrary code on compromised Linux systems. This involves creating or modifying cron files in specific directories such as \u003ccode\u003e/etc/cron.d/\u003c/code\u003e, \u003ccode\u003e/etc/cron.daily/\u003c/code\u003e, \u003ccode\u003e/var/spool/cron/crontabs/\u003c/code\u003e, and others. The creation of unexpected cron files by non-administrative users or during suspicious timeframes warrants investigation. While not all cron file creations are malicious, the potential for abuse necessitates monitoring for anomalous activity. Detecting the creation of new cron files can help identify potential persistence mechanisms being deployed by malicious actors.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Linux system, potentially through exploiting a vulnerability or using compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies cron job directories, such as \u003ccode\u003e/etc/cron.d/\u003c/code\u003e or \u003ccode\u003e/var/spool/cron/crontabs/\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new cron file within one of these directories.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe cron daemon automatically executes the commands specified in the newly created cron file according to the defined schedule.\u003c/li\u003e\n\u003cli\u003eThe attacker gains persistent access to the system, allowing them to maintain control even after reboots.\u003c/li\u003e\n\u003cli\u003eThe attacker may escalate privileges by scheduling commands that run with elevated permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the persistent access to perform further malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect New Cron File Creation\u0026rdquo; to your SIEM to detect the creation of cron files in cron directories and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor file creation events in cron directories such as \u003ccode\u003e/etc/cron.d/\u003c/code\u003e, \u003ccode\u003e/etc/cron.daily/\u003c/code\u003e, \u003ccode\u003e/etc/cron.hourly/\u003c/code\u003e, \u003ccode\u003e/etc/cron.monthly/\u003c/code\u003e, \u003ccode\u003e/etc/cron.weekly/\u003c/code\u003e, \u003ccode\u003e/var/spool/cron/crontabs/\u003c/code\u003e, and \u003ccode\u003e/var/spool/cron/root\u003c/code\u003e using file_event logs.\u003c/li\u003e\n\u003cli\u003eBaseline normal cron file creation activity and apply additional filters to reduce false positives based on the specific environment, as mentioned in the rule description.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-linux-cron-persistence/","summary":"An attacker may create new cron files in cron directories to establish persistence on a Linux system, potentially leading to privilege escalation and arbitrary code execution.","title":"Linux Cron File Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-03-linux-cron-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","pim","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003ePrivileged Identity Management (PIM) is a critical component of Azure Active Directory, enabling organizations to manage, control, and monitor access to important resources. Attackers often target PIM configurations to escalate privileges, establish persistence, or move laterally within a compromised environment. This activity focuses on detecting changes to PIM role settings, which could indicate malicious activity aimed at weakening security controls. Defenders must monitor these changes to prevent unauthorized access and maintain the integrity of their Azure environment. This includes understanding who is making these changes, the scope of the modifications, and whether the changes align with established security policies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e The attacker gains initial access to an account with sufficient privileges to view PIM settings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates existing PIM role settings within the Azure Active Directory environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModification:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e By modifying PIM settings, the attacker escalates their privileges, granting themselves elevated access to sensitive resources or administrative functions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating new or modifying existing role assignments to maintain access even if their initial account is compromised.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With escalated privileges, the attacker moves laterally to access other resources or accounts within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e The attacker leverages their escalated privileges to exfiltrate sensitive data, disrupt services, or cause other damage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect changes to PIM settings based on the \u003ccode\u003eproperties.message\u003c/code\u003e field within Azure audit logs.\u003c/li\u003e\n\u003cli\u003eRegularly 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.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all accounts with privileges to manage PIM settings.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by granting users only the minimum permissions required to perform their job functions.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of normal PIM settings and alert on any deviations from this baseline.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule by correlating them with other security events and user activity.\u003c/li\u003e\n\u003cli\u003eImplement automated responses to detected PIM setting modifications, such as disabling the affected user account or reverting the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-azure-pim-settings-change/","summary":"Detects unauthorized or malicious modifications to Privileged Identity Management (PIM) settings within Azure environments, potentially leading to privilege escalation, persistence, and stealthy access by attackers.","title":"Detection of Privileged Identity Management (PIM) Settings Modifications","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-pim-settings-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","cloud","service principal","persistence","lateral movement"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe creation of service principals in Azure can be a legitimate administrative task, but it can also be an indicator of malicious activity. Attackers may create service principals to establish persistence, move laterally within the Azure environment, or gain unauthorized access to resources. This activity is particularly concerning when performed by unfamiliar users or from unusual locations. Monitoring for unexpected service principal creation is crucial for detecting potential security breaches in Azure environments. This alert focuses on detecting the \u0026ldquo;Add service principal\u0026rdquo; message within Azure Activity Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the \u0026ldquo;Add service principal\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Service Principal Created\u0026rdquo; to your SIEM and tune for your environment to detect suspicious service principal creations.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u0026ldquo;Azure Service Principal Created\u0026rdquo; rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.\u003c/li\u003e\n\u003cli\u003eReview and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-azure-sp-creation/","summary":"Detects the creation of a service principal in Azure, which could indicate potential attacker activity for lateral movement or persistence.","title":"Detection of Azure Service Principal Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-sp-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Identity Center"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","identity","persistence","credential-access","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Identity Center (formerly AWS SSO) enables centralized management of access to AWS accounts and applications. Attackers can manipulate the configured identity provider to gain unauthorized access. The modification of the configured Identity Provider (IdP) within AWS Identity Center can lead to a full compromise of the AWS environment. By associating a malicious directory or disabling/disassociating legitimate directories, attackers can potentially establish persistent access, escalate privileges, and impersonate legitimate users. This can be achieved by utilizing compromised AWS credentials or exploiting vulnerabilities in the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.\u003c/li\u003e\n\u003cli\u003eThe attacker disassociates the existing, legitimate directory using \u003ccode\u003eDisassociateDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker associates a malicious directory they control using \u003ccode\u003eAssociateDirectory\u003c/code\u003e. This malicious directory is configured to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker disables external IdP configuration for the directory using \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events related to \u003ccode\u003eAssociateDirectory\u003c/code\u003e, \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e, \u003ccode\u003eDisassociateDirectory\u003c/code\u003e, or \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM permissions to minimize the blast radius of compromised credentials.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-aws-idp-change/","summary":"An adversary modifies the AWS Identity Center identity provider configuration, potentially leading to persistent access and privilege escalation through user impersonation.","title":"AWS Identity Center Identity Provider Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-idp-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3 Browser utility, a Windows-based client for managing Amazon S3 storage and other cloud services, can be abused by threat actors to create new IAM users or access keys within compromised AWS environments. This activity, if unauthorized, can lead to privilege escalation, persistence, or even initial access, depending on the context of the compromise. The use of S3 Browser is identifiable via the userAgent string in AWS CloudTrail logs. While legitimate use of S3 Browser for administrative tasks exists, its unexpected appearance in user activity, particularly in sensitive accounts, should be investigated. This activity is particularly concerning because it can allow attackers to establish a foothold in the cloud environment and move laterally.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker installs and configures S3 Browser on a compromised host or uses an existing installation.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses S3 Browser to execute the \u003ccode\u003eCreateUser\u003c/code\u003e API call within AWS IAM.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the new IAM user with elevated privileges, potentially granting administrator access.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses S3 Browser to execute the \u003ccode\u003eCreateAccessKey\u003c/code\u003e API call for an existing IAM user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created access key to perform actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser User or AccessKey Creation\u0026rdquo; to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eCreateUser\u003c/code\u003e or \u003ccode\u003eCreateAccessKey\u003c/code\u003e events in AWS CloudTrail logs where the \u003ccode\u003euserAgent\u003c/code\u003e contains \u0026ldquo;S3 Browser\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-s3browser-iam/","summary":"The use of S3 Browser to create IAM users or access keys in AWS environments indicates a potential privilege escalation, persistence, or initial access attempt by threat actors leveraging a known cloud administration tool.","title":"AWS IAM User or Access Key Creation via S3 Browser","url":"https://feed.craftedsignal.io/briefs/2024-01-03-s3browser-iam/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["cloud","azure","application","uri","modification","persistence","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify application URIs within Azure Active Directory to redirect users or applications to malicious resources, obtain unauthorized access, or establish persistence. The modification of an application\u0026rsquo;s URI can be a subtle but effective technique for gaining a foothold in an environment. By manipulating the URI settings, attackers can redirect traffic to attacker-controlled servers, intercept credentials, or perform other malicious actions. This activity is often difficult to detect because it can blend in with legitimate administrative tasks. Investigation is merited if URIs for domain names no longer exist, are not using HTTPS, have wildcards at the end of the domain, are not unique to that app, or point to domains that the organization does not control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory portal.\u003c/li\u003e\n\u003cli\u003eThe attacker locates a target application registration.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the application\u0026rsquo;s URI settings, such as the reply URLs or identifier URIs.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the URI to point to a malicious server or a phishing page.\u003c/li\u003e\n\u003cli\u003eUsers or applications are redirected to the malicious URI when attempting to authenticate or access the application.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts credentials or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining control over the application\u0026rsquo;s URI settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to determine if the URI modification is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for any changes to application URI settings (as indicated by \u003ccode\u003eproperties.message: Update Application Sucess- Property Name AppAddress\u003c/code\u003e) and validate the legitimacy of the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:21:00Z","date_published":"2024-01-03T14:21:00Z","id":"/briefs/2024-01-03-azure-app-uri-modification/","summary":"Detection of Azure application URI modifications that can be indicative of malicious activity, such as using dangling URIs, non-HTTPS URIs, wildcard domains, or URIs pointing to uncontrolled domains, potentially leading to initial access, stealth, persistence, credential access, and privilege escalation.","title":"Azure Application URI Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-app-uri-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","SentinelOne Cloud Funnel","Elastic Defend"],"_cs_severities":["low"],"_cs_tags":["persistence","user-account-creation","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers may create new accounts (both local and domain) to maintain access to victim systems. This rule identifies the usage of \u003ccode\u003enet.exe\u003c/code\u003e to create new accounts on Windows systems. The detection logic focuses on process execution events where \u003ccode\u003enet.exe\u003c/code\u003e or \u003ccode\u003enet1.exe\u003c/code\u003e are executed with arguments indicative of user creation, specifically the \u0026lsquo;user\u0026rsquo; argument in conjunction with either the \u0026lsquo;/ad\u0026rsquo; or \u0026lsquo;/add\u0026rsquo; flags. While account creation is a common administrative task, suspicious executions, especially those initiated by unusual parent processes or accounts, warrant further investigation. This rule is designed for data generated by Elastic Defend but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel, enhancing its applicability across various security environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker opens a command prompt or PowerShell session.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003enet.exe\u003c/code\u003e or \u003ccode\u003enet1.exe\u003c/code\u003e to create a new user account. The command includes the \u003ccode\u003euser\u003c/code\u003e argument along with \u003ccode\u003e/add\u003c/code\u003e or \u003ccode\u003e/ad\u003c/code\u003e flags. For example: \u003ccode\u003enet user \u0026lt;username\u0026gt; \u0026lt;password\u0026gt; /add\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker may add the newly created user to privileged groups, such as \u003ccode\u003eAdministrators\u003c/code\u003e or \u003ccode\u003eDomain Admins\u003c/code\u003e, to elevate privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new account to move laterally within the network, accessing sensitive data or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by configuring the new account to be a service account or adding it to local administrator groups.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003eAdministrators\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process-creation logging to capture the necessary events for the rules below.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003enet.exe\u003c/code\u003e or \u003ccode\u003enet1.exe\u003c/code\u003e creating user accounts, especially when initiated by unusual parent processes.\u003c/li\u003e\n\u003cli\u003eMonitor for newly created accounts being added to privileged groups.\u003c/li\u003e\n\u003cli\u003eReview the triage and analysis steps in the rule\u0026rsquo;s original documentation for guidance on investigating and responding to potential incidents.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-user-account-creation/","summary":"This rule identifies attempts to create new users on Windows systems using net.exe, a common tactic used by attackers to increase access or establish persistence.","title":"Windows User Account Creation via Net.exe","url":"https://feed.craftedsignal.io/briefs/2024-01-user-account-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["persistence","startup","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eAttackers often leverage the Windows Startup folder to maintain persistence, as any executable placed in this folder will automatically run when a user logs into the system. This technique is particularly effective because it requires no user interaction and can easily be automated. This rule detects when processes commonly abused by attackers, such as cmd.exe, powershell.exe, or mshta.exe, write or modify files within the Startup folders. The rule focuses on identifying unauthorized persistence mechanisms and helps defenders uncover potentially compromised systems. By monitoring file creation events in the Startup folders by suspicious processes, this detection aims to catch malicious activity early in the attack chain.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes a command shell (e.g., \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the command shell to write a malicious executable or script file to one of the Windows Startup folders (\u003ccode\u003eC:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*\u003c/code\u003e or \u003ccode\u003eC:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\StartUp\\\\*\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the file attributes (e.g., using \u003ccode\u003eattrib.exe\u003c/code\u003e) to hide the file or make it more difficult to detect.\u003c/li\u003e\n\u003cli\u003eThe attacker schedules a reboot or waits for the user to log off and back on.\u003c/li\u003e\n\u003cli\u003eUpon user logon, the malicious executable or script in the Startup folder is automatically executed.\u003c/li\u003e\n\u003cli\u003eThe malicious code establishes persistence, potentially downloading additional payloads or establishing a command and control (C2) channel.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the compromised system, enabling further malicious activities such as data theft or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s ability to move laterally. Sectors commonly targeted by persistence techniques include finance, healthcare, and government.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon Event ID 11 (File Create) to capture file creation events, as referenced in the \u003ca href=\"#setup\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Process Writing to Startup Folder\u003c/code\u003e to your SIEM to detect suspicious processes creating files in the startup folder, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine if the activity is malicious, referencing the \u003ca href=\"#note\"\u003einvestigation guide\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eBlock the processes listed in the rule (\u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, etc.) from writing to the startup folders if legitimate use is not required.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-startup-persistence/","summary":"Adversaries may establish persistence by writing malicious files to the Windows Startup folder, allowing them to automatically execute upon user logon; this detection identifies suspicious processes creating files in these locations.","title":"Suspicious Process Writing to Startup Folder for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-startup-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["MsMpEng.exe","Windows Defender","TeamViewer","SentinelOne Cloud Funnel","Microsoft Defender XDR"],"_cs_severities":["medium"],"_cs_tags":["remotemonologue","defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","TeamViewer","SentinelOne"],"content_html":"\u003cp\u003eThe RemoteMonologue attack technique abuses Component Object Model (COM) objects to coerce authentication from a remote system. This is achieved by modifying the \u003ccode\u003eRunAs\u003c/code\u003e registry value associated with a COM object. Setting this value to \u0026ldquo;Interactive User\u0026rdquo; forces the COM object to run under the context of the interactive user, enabling attackers to hijack sessions and potentially escalate privileges. This technique is often used as a defense evasion or persistence mechanism by adversaries after gaining initial access to a system. The attack involves modifying registry keys associated with COM objects to trigger NTLM authentication coercion. This can be used for lateral movement and gaining access to sensitive resources. This rule is designed to detect registry modifications indicative of the RemoteMonologue attack.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains initial access to the target system through unspecified means.\u003c/li\u003e\n\u003cli\u003eIdentify COM Objects: The attacker identifies suitable COM objects for abuse.\u003c/li\u003e\n\u003cli\u003eModify Registry: The attacker modifies the registry to set the \u003ccode\u003eRunAs\u003c/code\u003e value for the selected COM object to \u003ccode\u003eInteractive User\u003c/code\u003e. This involves modifying the registry path \u003ccode\u003eHKCR\\AppID\\{Clsid}\\RunAs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eTrigger 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.\u003c/li\u003e\n\u003cli\u003eAuthentication Coercion: The execution of the COM object triggers NTLM authentication to a system controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eRelay Attack: The attacker relays the coerced NTLM authentication to gain access to other resources on the network.\u003c/li\u003e\n\u003cli\u003eSession Hijacking: Successful relay leads to session hijacking, allowing the attacker to impersonate the user.\u003c/li\u003e\n\u003cli\u003eLateral Movement/Privilege Escalation: The attacker uses the hijacked session for lateral movement or privilege escalation within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect RemoteMonologue Registry Modification\u003c/code\u003e to your SIEM to identify suspicious registry modifications related to COM object hijacking.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring on critical systems to detect any attempts to modify COM object registry settings.\u003c/li\u003e\n\u003cli\u003eBlock the attack by ensuring \u0026ldquo;RunAs\u0026rdquo; value is not set to \u0026ldquo;Interactive User\u0026rdquo;.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-remotemonologue-regmod/","summary":"This rule detects potential RemoteMonologue attacks by identifying attempts to perform session hijacking via COM object registry modification, specifically when the RunAs value is set to Interactive User.","title":"Potential RemoteMonologue Attack via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-remotemonologue-regmod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Veeam Backup","PDQ Deploy","Pella Order Management","eset-remote-install-service"],"_cs_severities":["medium"],"_cs_tags":["lateral-movement","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Veeam","Admin Arsenal","Pella Corporation","ESET"],"content_html":"\u003cp\u003eThis detection rule identifies a potential lateral movement technique where an attacker establishes a network logon to a Windows system and subsequently installs a service using the same LogonId. This behavior is flagged as suspicious because it deviates from typical administrative practices and can indicate unauthorized access and persistence within the network. The rule is designed to filter out common legitimate services and administrative activities, focusing on anomalies that could signify malicious intent. This detection is crucial for defenders as it can uncover attackers attempting to move laterally and establish persistent access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a network via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker performs network reconnaissance to identify target systems for lateral movement.\u003c/li\u003e\n\u003cli\u003eUsing valid credentials or pass-the-hash techniques, the attacker authenticates to a remote Windows host over the network (e.g., SMB).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to install a new service on the remote host, potentially using tools like \u003ccode\u003esc.exe\u003c/code\u003e or PowerShell.\u003c/li\u003e\n\u003cli\u003eThe service installation event is logged with a specific LogonId that matches the earlier network logon event, indicating a relationship between the two activities.\u003c/li\u003e\n\u003cli\u003eThe newly installed service is configured to execute a malicious payload or establish a reverse shell.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the service to execute commands or deploy further malicious tools on the compromised host.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence and lateral movement within the network, enabling further compromise and data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Security Event Logs with necessary auditing policies, specifically Audit Logon and Audit Security System Extension, to capture relevant logon and service installation events.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect suspicious remote service installations based on matching LogonIds from network logons.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on unusual service file paths and user accounts.\u003c/li\u003e\n\u003cli\u003eReview the list of excluded service file paths in the Sigma rules and customize them based on your environment\u0026rsquo;s known legitimate services.\u003c/li\u003e\n\u003cli\u003eMonitor network connections for suspicious SMB activity, particularly connections originating from unusual or untrusted sources.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to reduce the risk of credential theft and unauthorized network access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-remote-service-install/","summary":"This rule detects a network logon followed by Windows service creation with the same LogonId on a Windows host, which could indicate lateral movement or persistence by adversaries.","title":"Detecting Remote Windows Service Installation for Lateral Movement","url":"https://feed.craftedsignal.io/briefs/2024-01-remote-service-install/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["impact","t1490","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may disable the Windows System Restore feature to prevent victims from easily reverting their systems to a clean state after an infection or other malicious activity. This action complicates incident response and remediation efforts, forcing more complex and time-consuming recovery procedures. Disabling system restore is often performed post-compromise to ensure persistence and hinder forensic analysis. This technique can be implemented manually through the registry editor or via automated scripts, making it accessible to a wide range of threat actors.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained through various methods (e.g., phishing, exploitation).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to Administrator or SYSTEM.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell to modify registry keys.\u003c/li\u003e\n\u003cli\u003eThe attacker targets the \u003ccode\u003eHKLM\\Software\\Policies\\Microsoft\\Windows NT\\SystemRestore\\DisableConfig\u003c/code\u003e registry key.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker targets the \u003ccode\u003eHKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\SystemRestore\\DisableSR\u003c/code\u003e registry key.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the value of the targeted registry key to \u003ccode\u003eDWORD:00000001\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker confirms the System Restore feature is disabled.\u003c/li\u003e\n\u003cli\u003eThe attacker proceeds with further malicious activities, knowing that recovery is hindered.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eRegistry Disable System Restore\u003c/code\u003e to your SIEM to detect malicious attempts to disable System Restore via registry modification.\u003c/li\u003e\n\u003cli\u003eMonitor registry modifications related to System Restore configurations, focusing on the keys \u003ccode\u003e\\Policies\\Microsoft\\Windows NT\\SystemRestore\u003c/code\u003e and \u003ccode\u003e\\Microsoft\\Windows NT\\CurrentVersion\\SystemRestore\u003c/code\u003e, and values set to \u003ccode\u003eDWORD (0x00000001)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls to prevent unauthorized modification of registry settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-disable-system-restore/","summary":"Attackers disable Windows System Restore by modifying specific registry keys to hinder recovery efforts after malicious activity.","title":"Windows System Restore Disabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-disable-system-restore/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike FDR","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","lateral-movement","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThe legacy Windows AT command allows scheduling tasks for execution. While deprecated since Windows 8 and Windows Server 2012, it remains present for backwards compatibility. Attackers may enable the AT command through registry modifications to achieve persistence or lateral movement within a network. This technique bypasses modern security controls and can be difficult to detect without specific monitoring. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. The use of this command allows an attacker to execute commands with elevated privileges, potentially compromising the entire system.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enable the AT command by modifying the registry.\u003c/li\u003e\n\u003cli\u003eThe registry key \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt\u003c/code\u003e is modified to a value of \u0026ldquo;1\u0026rdquo; or \u0026ldquo;0x00000001\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AT command to schedule a malicious task.\u003c/li\u003e\n\u003cli\u003eThe scheduled task executes a command or script, such as downloading and executing malware.\u003c/li\u003e\n\u003cli\u003eThe malware establishes persistence on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised system as a pivot point for lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eEnabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry events for modifications to \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt\u003c/code\u003e as described in the rule overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Scheduled Tasks AT Command Enabled\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation and registry event logging to activate the rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule \u0026ldquo;Scheduled Tasks AT Command Enabled\u0026rdquo; for suspicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-at-command-enabled/","summary":"Attackers may enable the deprecated Windows AT command via registry modification to achieve local persistence or lateral movement.","title":"Windows Scheduled Tasks AT Command Enabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-at-command-enabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","root certificate","mitm"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eAttackers can install malicious root certificates to subvert trust controls and bypass security measures. Once a malicious root certificate is installed, attackers can sign malicious files, making them appear as legitimate software from trusted vendors like Microsoft. This allows the attacker to execute code undetected and maintain persistence on the system. Furthermore, a rogue root certificate can be used in adversary-in-the-middle attacks to decrypt SSL traffic, enabling the collection of sensitive data. This activity is typically achieved through registry modifications. Monitoring for these modifications can help security teams identify potential compromise attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system, possibly through phishing or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to administrator or SYSTEM level, required to modify the trusted root certificate store.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools like certutil.exe or PowerShell to import a malicious root certificate into the Windows registry.\u003c/li\u003e\n\u003cli\u003eThe registry keys \u003ccode\u003eHKLM\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\u003c/code\u003e or \u003ccode\u003eHKLM\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\u003c/code\u003e are modified to add the new certificate.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly installed root certificate to sign malicious executables or scripts.\u003c/li\u003e\n\u003cli\u003eThe signed malicious files are executed, bypassing signature-based detection mechanisms.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts and decrypts SSL traffic, collecting sensitive data like credentials or financial information.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the trusted certificate to repeatedly sign and execute malicious code.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Root Certificate Modification\u0026rdquo; to your SIEM to detect registry modifications related to root certificate installation.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the necessary data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on processes modifying the registry keys related to root certificates.\u003c/li\u003e\n\u003cli\u003eReview the \u0026ldquo;False Positives\u0026rdquo; section in the rule documentation to tune the Sigma rule for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious SSL decryption activity following the detection of a root certificate modification.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-root-cert-modification/","summary":"The modification of root certificates on Windows systems by unauthorized processes can allow attackers to masquerade malicious files as valid signed components and intercept/decrypt SSL traffic, leading to defense evasion and data collection.","title":"Windows Root Certificate Modification Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-root-cert-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["high"],"_cs_tags":["defense-evasion","persistence","windows","access-control"],"_cs_type":"advisory","_cs_vendors":["Splunk"],"content_html":"\u003cp\u003eThis analytic detects the modification of file and directory security permissions through command-line tools like icacls.exe, cacls.exe, and xcacls.exe. These tools are legitimate Windows utilities but are often abused by threat actors, including APT groups and coinminer scripts, to evade detection, maintain persistence, and hinder incident response. The detection focuses on command-line arguments indicating modifications to access rights (e.g., granting full control or modifying permissions). Detecting this activity is crucial as it can lead to unauthorized access, data exfiltration, and system compromise, ultimately impeding remediation efforts and prolonging the attacker\u0026rsquo;s presence on the compromised system. The detection leverages endpoint detection and response (EDR) data focusing on process execution and command-line analysis.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains initial access to the system through methods such as phishing, exploiting vulnerabilities, or compromised credentials.\u003c/li\u003e\n\u003cli\u003ePrivilege 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.\u003c/li\u003e\n\u003cli\u003eTool Deployment: The attacker deploys or utilizes existing system tools like \u003ccode\u003eicacls.exe\u003c/code\u003e, \u003ccode\u003ecacls.exe\u003c/code\u003e, or \u003ccode\u003excacls.exe\u003c/code\u003e to modify access control lists (ACLs) on files and directories.\u003c/li\u003e\n\u003cli\u003eAccess 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 \u003ccode\u003e*:R*\u003c/code\u003e, \u003ccode\u003e*:W*\u003c/code\u003e, \u003ccode\u003e*:F*\u003c/code\u003e, \u003ccode\u003e*:C*\u003c/code\u003e, \u003ccode\u003e*:N*\u003c/code\u003e, \u003ccode\u003e*/P*\u003c/code\u003e, and \u003ccode\u003e*/E*\u003c/code\u003e are used to manipulate access rights.\u003c/li\u003e\n\u003cli\u003eDefense 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.\u003c/li\u003e\n\u003cli\u003ePersistence: 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.\u003c/li\u003e\n\u003cli\u003eLateral 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.\u003c/li\u003e\n\u003cli\u003eImpact: 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging (Event ID 1) to capture the execution of \u003ccode\u003eicacls.exe\u003c/code\u003e, \u003ccode\u003ecacls.exe\u003c/code\u003e, and \u003ccode\u003excacls.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious Icacls Usage\u0026rdquo; to your SIEM to identify instances of access right modifications via icacls.exe, cacls.exe, and xcacls.exe.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where these tools are used to modify access rights, especially when command-line arguments include \u003ccode\u003e*:R*\u003c/code\u003e, \u003ccode\u003e*:W*\u003c/code\u003e, \u003ccode\u003e*:F*\u003c/code\u003e, \u003ccode\u003e*:C*\u003c/code\u003e, \u003ccode\u003e*:N*\u003c/code\u003e, \u003ccode\u003e*/P*\u003c/code\u003e, and \u003ccode\u003e*/E*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Windows Event Log Security (4688) for process creation events to correlate with Sysmon data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-icacls-access-rights-modification/","summary":"Detection of icacls.exe, cacls.exe, or xcacls.exe being used to modify file or directory permissions, often used by APTs and coinminers for defense evasion and persistence.","title":"Windows Files and Dirs Access Rights Modification via Icacls","url":"https://feed.craftedsignal.io/briefs/2024-01-icacls-access-rights-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR"],"_cs_severities":["low"],"_cs_tags":["persistence","registry_modification","werfault"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers can abuse the Windows Error Reporting (Werfault) service to establish persistence on a compromised system. This is achieved by modifying the ReflectDebugger registry key. When Werfault is executed with the \u003ccode\u003e-pr\u003c/code\u003e parameter, it will execute the debugger specified in the ReflectDebugger registry key. This allows attackers to execute arbitrary code every time the Windows Error Reporting utility is triggered. The technique involves modifying specific registry paths associated with the ReflectDebugger. This behavior has been documented as a persistence mechanism in malware analysis reports.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system through unspecified means.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to modify the Windows Error Reporting ReflectDebugger registry key.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the ReflectDebugger value within one of the following registry paths: \u003ccode\u003eHKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger\u003c/code\u003e, \u003ccode\u003e\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger\u003c/code\u003e, or \u003ccode\u003eMACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the ReflectDebugger value to a malicious executable or script.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers Werfault.exe with the \u003ccode\u003e-pr\u003c/code\u003e parameter, either manually or through a system event.\u003c/li\u003e\n\u003cli\u003eWerfault.exe executes the attacker-controlled code specified in the ReflectDebugger registry value.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence, as the malicious code is executed each time Werfault is triggered with the \u003ccode\u003e-pr\u003c/code\u003e parameter.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eWerfault ReflectDebugger Registry Modification\u003c/code\u003e to detect unauthorized modifications to the ReflectDebugger registry key (logsource: \u003ccode\u003eregistry_set\u003c/code\u003e, rule title).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to detect the execution of Werfault with the \u003ccode\u003e-pr\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for changes to the specific ReflectDebugger paths mentioned in the overview section (\u003ccode\u003eHKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-werfault-reflectdebugger-persistence/","summary":"Attackers may establish persistence by modifying the ReflectDebugger registry key associated with Windows Error Reporting to execute arbitrary code when Werfault is invoked with the '-pr' parameter.","title":"Werfault ReflectDebugger Persistence via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-werfault-reflectdebugger-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege_escalation","active_directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers often target Active Directory (AD) to gain control over a network. Adding a user account to a highly privileged group, such as Domain Admins or Enterprise Admins, is a common tactic for establishing persistence and escalating privileges. By compromising an account with the ability to manage group memberships or exploiting vulnerabilities, an attacker can add their own rogue account to a privileged group, granting them extensive control over the AD domain. This activity might go unnoticed amidst legitimate administrative actions, making it a stealthy method of maintaining unauthorized access. This is a common technique employed after initial compromise to ensure long-term access to critical systems and data. Detecting such additions requires careful monitoring of AD security logs for specific events related to group membership changes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a low-privileged user account through phishing or credential theft.\u003c/li\u003e\n\u003cli\u003eLateral movement to a system with access to Active Directory management tools.\u003c/li\u003e\n\u003cli\u003ePrivilege escalation to an account with permissions to modify group memberships (e.g., leveraging exploits or credential dumping).\u003c/li\u003e\n\u003cli\u003eUse 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).\u003c/li\u003e\n\u003cli\u003eThe attacker logs in with the newly privileged account.\u003c/li\u003e\n\u003cli\u003eThe attacker uses their elevated privileges to access sensitive data, install backdoors, or perform other malicious activities.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to remove the initially compromised account to remove traces of their activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Security Group Management\u0026rdquo; in Active Directory to generate the necessary security events for detecting group membership changes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;User Added to Privileged Group in Active Directory\u0026rdquo; to your SIEM to detect suspicious additions to privileged groups, tuning the rule for known administrative accounts.\u003c/li\u003e\n\u003cli\u003eMonitor for unexpected use of AD management tools, such as \u003ccode\u003eActive Directory Users and Computers\u003c/code\u003e or \u003ccode\u003ePowerShell\u003c/code\u003e with the \u003ccode\u003eAD\u003c/code\u003e module, especially from unusual source hosts.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eRegularly review the membership of privileged groups and remove any unauthorized or unnecessary accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-ad-privileged-group-addition/","summary":"Adversaries may add a user to a privileged group in Active Directory, such as Domain Admins, to maintain persistent access and elevate privileges within the domain.","title":"User Added to Privileged Group in Active Directory","url":"https://feed.craftedsignal.io/briefs/2024-01-ad-privileged-group-addition/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["low"],"_cs_tags":["persistence","scheduled-task","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies first-time modifications to scheduled tasks by non-system users on Windows systems. Adversaries frequently abuse scheduled tasks to achieve persistence by modifying existing tasks or creating new ones that execute malicious code at recurring intervals. This rule focuses on detecting unauthorized changes to existing tasks by filtering out known system accounts (SYSTEM, Local Service, Network Service) and machine accounts, thereby highlighting potentially suspicious user activity. The rule leverages Windows Security Event Logs (event code 4702) to monitor task modifications. The goal is to aid in the early detection of threats where attackers are attempting to establish persistence on a compromised system.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing scheduled tasks on the system using tools like \u003ccode\u003eschtasks.exe\u003c/code\u003e or PowerShell cmdlets.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a suitable scheduled task to modify for persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the task\u0026rsquo;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.\u003c/li\u003e\n\u003cli\u003eThe scheduled task is updated using \u003ccode\u003eschtasks.exe /change\u003c/code\u003e or PowerShell\u0026rsquo;s \u003ccode\u003eSet-ScheduledTask\u003c/code\u003e cmdlet.\u003c/li\u003e\n\u003cli\u003eThe modified scheduled task executes at the specified time, launching the attacker\u0026rsquo;s malicious payload.\u003c/li\u003e\n\u003cli\u003eThe malicious payload establishes a reverse shell to the attacker\u0026rsquo;s command and control (C2) server.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the reverse shell to perform further actions on the compromised system, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Other Object Access Events\u0026rdquo; to generate the required Windows Security Event Logs (event ID 4702) as described in the setup instructions.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to your SIEM to detect unusual scheduled task updates.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule to determine if the scheduled task modification is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eReview the references provided to understand the underlying event IDs and attacker techniques related to scheduled tasks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-unusual-scheduled-task-update/","summary":"This rule detects modifications to scheduled tasks by user accounts, excluding system activity and machine accounts, which adversaries can exploit for persistence by modifying them to execute malicious code.","title":"Unusual Scheduled Task Update","url":"https://feed.craftedsignal.io/briefs/2024-01-unusual-scheduled-task-update/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["persistence","windows","registry modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies processes that modify the Windows services registry key directly, bypassing the standard Windows APIs. This behavior can signify an adversary\u0026rsquo;s attempt to establish persistence stealthily by creating new services or altering existing ones in an unexpected manner. The detection logic focuses on changes to the \u003ccode\u003eServiceDLL\u003c/code\u003e and \u003ccode\u003eImagePath\u003c/code\u003e values within specific registry paths associated with service configurations. This rule is designed for data generated by Elastic Defend and also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon Registry Events. The rule helps security analysts identify potentially malicious activity related to service manipulation, which can lead to persistent access and control over compromised systems. The rule excludes known legitimate processes and paths to minimize false positives, focusing on anomalous registry modifications.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain administrative access, allowing them to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker directly modifies the \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL\u003c/code\u003e or \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath\u003c/code\u003e registry keys to point to a malicious DLL or executable.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.\u003c/li\u003e\n\u003cli\u003eThe compromised service starts automatically during system startup or manually when triggered by the attacker.\u003c/li\u003e\n\u003cli\u003eThe malicious service executes arbitrary code, providing the attacker with persistent control over the system.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).\u003c/li\u003e\n\u003cli\u003eTune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on processes modifying the \u003ccode\u003eServiceDLL\u003c/code\u003e or \u003ccode\u003eImagePath\u003c/code\u003e registry values (Sigma rules).\u003c/li\u003e\n\u003cli\u003eReview endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-unusual-registry-persistence/","summary":"Detection of processes modifying the Windows services registry key directly, potentially indicating stealthy persistence attempts via abnormal service creation or modification.","title":"Unusual Persistence via Services Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-unusual-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["persistence","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts on Windows systems. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The rule filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations. The rule focuses on changes to registry keys such as \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Winlogon\\\\Shell\u003c/code\u003e and \u003ccode\u003eHKEY_USERS\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Windows\\\\Run\u003c/code\u003e. This rule is designed for data generated by Elastic Defend and also supports third-party data sources such as Sysmon. The rule was last updated on 2026-05-04.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes code on the system, potentially using a dropper or exploit.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies uncommon registry keys suitable for persistence.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe system restarts, or the user logs in, triggering the execution of the malicious code through the modified registry key.\u003c/li\u003e\n\u003cli\u003eThe malicious code executes with the privileges of the user or system, depending on the registry key modified.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence, allowing them to maintain access to the system even after restarts.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities such as data exfiltration, lateral movement, or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s objectives and the scope of the initial compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Uncommon Registry Persistence Change\u0026rdquo; Sigma rule to your SIEM to detect modifications to uncommon registry persistence keys and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to ensure the visibility required for the Sigma rule to function effectively (see references).\u003c/li\u003e\n\u003cli\u003eReview and tune the filter conditions in the Sigma rule to reduce false positives, specifically excluding legitimate software installations, system maintenance processes, and administrative scripts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the registry modification and correlating it with other suspicious activities.\u003c/li\u003e\n\u003cli\u003eBlock execution of known malicious executables and scripts identified during the investigation to prevent further compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-uncommon-registry-persistence/","summary":"This rule detects changes to uncommon registry persistence keys on Windows systems that are not commonly used or modified by legitimate programs, which could indicate an adversary's attempt to persist in a stealthy manner by modifying registry keys for persistence, ensuring malicious code executes on startup or during specific events.","title":"Uncommon Registry Persistence Change Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-uncommon-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","initial-access","persistence","stealth","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert detects instances where a user attempts to invite an external guest user to an Azure environment but fails due to insufficient permissions. This activity can signify several potential security risks, including unauthorized privilege escalation attempts by internal users or malicious insiders attempting to expand access without proper authorization. While legitimate failed attempts may occur, repeated or targeted failures should be investigated. The activity is logged within the Azure Audit Logs. Detecting this activity is crucial for maintaining control over user access and preventing potential data breaches. The relevant log data resides within Azure\u0026rsquo;s audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.\u003c/li\u003e\n\u003cli\u003eThe Azure Active Directory service checks the inviter\u0026rsquo;s permissions against the organization\u0026rsquo;s guest invitation policies.\u003c/li\u003e\n\u003cli\u003eThe system determines the user lacks the necessary permissions to invite guest users.\u003c/li\u003e\n\u003cli\u003eAzure Audit Logs record the \u0026ldquo;Invite external user\u0026rdquo; event with a \u0026ldquo;failure\u0026rdquo; status.\u003c/li\u003e\n\u003cli\u003eThe failed invitation attempt is blocked, preventing the external user from gaining access.\u003c/li\u003e\n\u003cli\u003eThe attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.\u003c/li\u003e\n\u003cli\u003eIf successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Guest User Invited By Non Approved Inviters\u0026rdquo; to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.\u003c/li\u003e\n\u003cli\u003eMonitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-guest-invite-failure/","summary":"Detection of a failed attempt to invite an external guest user by an Azure user lacking the necessary permissions, potentially indicating privilege escalation or malicious insider activity.","title":"Unauthorized Guest User Invitation Attempt in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-guest-invite-failure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["high"],"_cs_tags":["defense-evasion","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Splunk"],"content_html":"\u003cp\u003eThis threat brief addresses the tactic of executing processes from suspicious file paths within Windows environments, a common technique used by adversaries to bypass security controls and execute malicious code without requiring elevated privileges. This activity is often observed in post-exploitation scenarios, where attackers have already gained initial access and are attempting to establish persistence or escalate their privileges. Attackers often leverage these unconventional locations to avoid detection by traditional security solutions that rely on whitelisting or reputation-based analysis. The detection focuses on identifying processes running from paths like \u003ccode\u003e\\Windows\\Fonts\\\u003c/code\u003e, \u003ccode\u003e\\Users\\Public\\\u003c/code\u003e, \u003ccode\u003e\\Windows\\Debug\\\u003c/code\u003e, and others, as these are not typically associated with legitimate software execution. This technique has been associated with malware families like AsyncRAT, RedLine Stealer, and LockBit Ransomware.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained through phishing, exploitation of a vulnerability, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads or creates a malicious executable or script (e.g., PowerShell script) in a suspicious directory such as \u003ccode\u003eC:\\Windows\\Fonts\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe malicious process begins execution from the unusual file path.\u003c/li\u003e\n\u003cli\u003eThe process performs malicious activities, such as downloading additional payloads, establishing command and control (C2) communication, or conducting reconnaissance.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised process to escalate privileges or move laterally within the network.\u003c/li\u003e\n\u003cli\u003eData exfiltration or encryption may occur, depending on the attacker\u0026rsquo;s objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to maintain persistence by creating scheduled tasks or modifying registry keys to ensure the malicious process restarts upon system reboot.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Process Executing from Common Non-Executable Paths\u0026rdquo; to your SIEM to detect processes running from unusual file paths. Tune the rule to filter out any legitimate exceptions in your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, paying close attention to the process name, command line, and parent process.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unauthorized software in your environment.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious outbound connections originating from processes running from unusual file paths.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-suspicious-process-path/","summary":"Attackers may execute malicious code from unusual file paths such as Windows fonts or debug directories to evade defenses and gain unauthorized access, as detected by endpoint detection and response (EDR) agents.","title":"Suspicious Process Execution from Unusual File Paths","url":"https://feed.craftedsignal.io/briefs/2024-01-03-suspicious-process-path/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","Elastic Endgame","Windows Security Event Logs","Crowdstrike"],"_cs_severities":["medium"],"_cs_tags":["execution","persistence","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","Crowdstrike"],"content_html":"\u003cp\u003eThe rule detects suspicious usage of \u003ccode\u003emofcomp.exe\u003c/code\u003e, a command-line tool used to compile Managed Object Format (MOF) files. Attackers can abuse MOF files to manipulate the Windows Management Instrumentation (WMI) repository by building malicious WMI scripts for persistence or execution. This can be achieved by creating their own namespaces and classes within WMI or establishing persistence through WMI Event Subscriptions. The rule identifies unusual mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes like \u003ccode\u003eScenarioEngine.exe\u003c/code\u003e and system accounts (\u003ccode\u003eS-1-5-18\u003c/code\u003e). This detection is designed to work with data from Elastic Defend, Microsoft Defender XDR, Crowdstrike, and Windows Security Event Logs. The rule aims to detect potential misuse of WMI for malicious purposes, enhancing the visibility of attacker techniques for execution and persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker uploads a malicious MOF file to the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003emofcomp.exe\u003c/code\u003e to compile the malicious MOF file.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emofcomp.exe\u003c/code\u003e processes the MOF file, creating new namespaces and classes or modifying existing ones in the WMI repository.\u003c/li\u003e\n\u003cli\u003eIf the MOF file creates a WMI Event Subscription, it triggers the execution of a malicious script or binary when a specific event occurs.\u003c/li\u003e\n\u003cli\u003eThe malicious script or binary executes, performing actions such as installing malware, creating backdoors, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence through the WMI Event Subscription, ensuring continued access even after system reboots.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect suspicious \u003ccode\u003emofcomp.exe\u003c/code\u003e activity and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging and command-line auditing on Windows systems to capture necessary events for the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on unusual MOF file paths, parent processes, and user accounts.\u003c/li\u003e\n\u003cli\u003eReview and monitor WMI namespaces and classes for unauthorized modifications or additions following any detected suspicious \u003ccode\u003emofcomp.exe\u003c/code\u003e activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-mofcomp-activity/","summary":"This rule detects suspicious mofcomp.exe activity, which attackers may leverage MOF files to manipulate the Windows Management Instrumentation (WMI) repository for execution and persistence by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts.","title":"Suspicious Mofcomp Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-mofcomp-activity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel","CrowdStrike FDR","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","registry-modification","ssp"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers can abuse the Windows Security Support Provider (SSP) mechanism to establish persistence on a compromised system. SSPs are DLLs loaded into the Local Security Authority Subsystem Service (LSASS) process, which handles authentication in Windows. By modifying specific registry keys related to SSP configuration, attackers can force LSASS to load malicious DLLs at startup, effectively creating a persistent backdoor. This technique is often used to maintain unauthorized access to a system even after a reboot. The registry keys of interest are \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e and \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e. Successful exploitation allows the attacker to intercept and manipulate authentication credentials.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through an exploit or compromised credentials (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain administrative rights on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e to include a path to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the registry key \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e to include a path to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers a system reboot, or restarts the LSASS process, causing the malicious SSP DLL to be loaded.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL intercepts authentication credentials and exfiltrates them or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the system, even after reboots.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious SSP Registry Modification\u0026rdquo; to your SIEM to detect unauthorized modifications to SSP registry keys.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.\u003c/li\u003e\n\u003cli\u003eContinuously monitor for unexpected processes writing to the \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e and \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e registry keys.\u003c/li\u003e\n\u003cli\u003eReview and whitelist legitimate software installers that frequently modify these registry entries to reduce false positives as mentioned in the brief.\u003c/li\u003e\n\u003cli\u003eEnsure access controls and permissions are strictly enforced to limit unauthorized modification of critical registry paths related to Security Support Providers.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-ssp-registry-modification/","summary":"Adversaries may modify the Windows Security Support Provider (SSP) configuration in the registry to establish persistence or evade defenses.","title":"Suspicious Modifications to Windows Security Support Provider (SSP) Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-ssp-registry-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Word","Excel","PowerPoint","Publisher","Access"],"_cs_severities":["low"],"_cs_tags":["persistence","execution","windows","image_load","scheduled_task"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies a suspicious image load (\u003ccode\u003etaskschd.dll\u003c/code\u003e) originating from Microsoft Office applications (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE). The behavior suggests potential adversarial activity involving the creation of scheduled tasks through the Windows Component Object Model (COM). Attackers may exploit this technique to establish persistence, circumventing traditional monitoring focused on the \u003ccode\u003eschtasks.exe\u003c/code\u003e utility. The use of COM for scheduled task management allows for stealthier operation and evasion of standard security controls, making it a valuable persistence mechanism for malicious actors. The rule is designed for data generated by Elastic Defend, Sysmon, and other endpoint detection platforms.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser opens a malicious Microsoft Office document (e.g., Word, Excel).\u003c/li\u003e\n\u003cli\u003eThe document executes embedded macro code or exploits a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe macro or exploit leverages the Component Object Model (COM).\u003c/li\u003e\n\u003cli\u003eThe Office application (e.g., WINWORD.EXE) loads the \u003ccode\u003etaskschd.dll\u003c/code\u003e library, providing access to the Task Scheduler service.\u003c/li\u003e\n\u003cli\u003eThe COM interface is used to programmatically create a new scheduled task.\u003c/li\u003e\n\u003cli\u003eThe scheduled task is configured to execute a malicious payload at a later time or on a recurring basis.\u003c/li\u003e\n\u003cli\u003eThe malicious payload could be a script, executable, or command-line instruction.\u003c/li\u003e\n\u003cli\u003eUpon execution, the payload achieves the attacker\u0026rsquo;s objective, such as establishing persistence, downloading additional malware, or compromising the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Office Application Loading Task Scheduler DLL\u0026rdquo; to your SIEM and tune for your environment to detect this specific activity.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the specific scheduled tasks that are created and the payloads they execute.\u003c/li\u003e\n\u003cli\u003eMonitor for scheduled task creation events (Event ID 4698) and deletion events (Event ID 4699) in the Windows Event Logs, as referenced in the rule\u0026rsquo;s investigation guide.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-suspicious-image-load-office/","summary":"Detection of taskschd.dll image loads from Microsoft Office applications indicates potential COM-based scheduled task creation for persistence, bypassing traditional schtasks.exe usage.","title":"Suspicious Image Load (taskschd.dll) from MS Office","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-image-load-office/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon EC2"],"_cs_severities":["medium"],"_cs_tags":["aws","ec2","keypair","persistence","credential_access","lateral_movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft"],"content_html":"\u003cp\u003eThis alert identifies suspicious activity related to the creation of EC2 key pairs within an AWS environment. Specifically, it focuses on instances where a new IAM principal (user) creates an EC2 key pair from a network source (IP address) whose autonomous system organization is not commonly associated with major cloud providers like Amazon, Google, or Microsoft. Adversaries often create key pairs for persistence or to enable unauthorized access to EC2 instances, potentially leading to data exfiltration or further malicious activities. The rule uses a new terms approach to baseline user activity, reducing noise from repeated actions while still flagging the initial suspicious key pair creation. This activity is flagged as suspicious due to originating from outside trusted ASNs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances and associated key pairs.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateKeyPair\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eThe attacker stores the private key material for later use in accessing EC2 instances.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e operations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.\u003c/li\u003e\n\u003cli\u003eOnce inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003eCreateKeyPair\u003c/code\u003e event raises the risk profile.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 CreateKeyPair from Non-Cloud AS Organization\u0026rdquo; to your SIEM and tune the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions based on your environment.\u003c/li\u003e\n\u003cli\u003eReview AWS CloudTrail logs for any \u003ccode\u003eCreateKeyPair\u003c/code\u003e events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.\u003c/li\u003e\n\u003cli\u003eImplement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eMonitor for \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e events using the newly created key names as identified from \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e / \u003ccode\u003eresponse_elements\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-aws-ec2-keypair-creation/","summary":"An AWS EC2 CreateKeyPair event triggered by a new principal originating from a network autonomous system (AS) organization not associated with major cloud providers, indicating potential unauthorized access or persistence activity.","title":"Suspicious AWS EC2 Key Pair Creation from Non-Cloud AS","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ec2-keypair-creation/"}],"language":"en","next_url":"/tags/persistence/page/2/feed.json","title":"CraftedSignal Threat Feed — Persistence","version":"https://jsonfeed.org/version/1.1"}