{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/windows-security-event-logs/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","CrowdStrike","SentinelOne Cloud Funnel","Sysmon","Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["lolbas","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Crowdstrike","SentinelOne","Elastic"],"content_html":"\u003cp\u003eThe Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. This can be achieved by running cdb.exe from non-standard installation paths and using specific command-line arguments to execute malicious commands. The LOLBAS project documents this technique, highlighting its potential for defense evasion. This activity has been observed across various environments, necessitating detection strategies that focus on identifying anomalous executions of cdb.exe.\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.\u003c/li\u003e\n\u003cli\u003eThe attacker copies cdb.exe to a non-standard location (outside \u0026ldquo;Program Files\u0026rdquo; and \u0026ldquo;Program Files (x86)\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe attacker executes cdb.exe with the \u003ccode\u003e-cf\u003c/code\u003e, \u003ccode\u003e-c\u003c/code\u003e, or \u003ccode\u003e-pd\u003c/code\u003e command-line arguments.\u003c/li\u003e\n\u003cli\u003eThese arguments are used to specify a command file or execute a direct command.\u003c/li\u003e\n\u003cli\u003eThe command file or command directly executes malicious code, such as shellcode.\u003c/li\u003e\n\u003cli\u003eThe malicious code performs actions such as creating new processes, modifying files, or establishing network connections.\u003c/li\u003e\n\u003cli\u003eThese actions allow the attacker to maintain persistence or escalate privileges.\u003c/li\u003e\n\u003cli\u003eThe ultimate goal is to evade defenses and execute arbitrary code on the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows adversaries to execute arbitrary commands and shellcode on the affected system, potentially leading to complete system compromise. This can result in data theft, installation of malware, or further propagation within the network. The technique is effective at bypassing application whitelisting and other security controls that rely on standard execution paths.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Execution via Windows Command Debugging Utility\u0026rdquo; to your SIEM to detect suspicious cdb.exe executions (see rules section).\u003c/li\u003e\n\u003cli\u003eEnable process creation logging via Sysmon or Windows Security Event Logs to provide the necessary data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to prevent execution of cdb.exe from non-standard paths.\u003c/li\u003e\n\u003cli\u003eMonitor process command lines for the \u003ccode\u003e-cf\u003c/code\u003e, \u003ccode\u003e-c\u003c/code\u003e, and \u003ccode\u003e-pd\u003c/code\u003e flags when cdb.exe is executed.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of cdb.exe running from unusual directories to determine legitimacy.\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-cdb-execution/","summary":"Adversaries can abuse the Windows command line debugging utility cdb.exe to execute commands or shellcode from non-standard paths, evading traditional security measures.","title":"Suspicious Execution via Windows Command Debugging Utility","url":"https://feed.craftedsignal.io/briefs/2024-07-cdb-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Endgame","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Sysmon","Windows Security Event Logs","Crowdstrike"],"_cs_severities":["high"],"_cs_tags":["credential-access","registry-dump","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection identifies attempts to export registry hives containing sensitive credential information using the Windows \u003ccode\u003ereg.exe\u003c/code\u003e utility. Attackers may target the \u003ccode\u003eHKLM\\SAM\u003c/code\u003e and \u003ccode\u003eHKLM\\SECURITY\u003c/code\u003e hives to extract stored credentials, including password hashes and LSA secrets. The activity is often part of a broader credential access campaign. The rule focuses on detecting the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with specific arguments indicating an attempt to save or export these critical registry hives. The use of \u003ccode\u003ereg.exe\u003c/code\u003e makes this technique accessible to various threat actors, including ransomware groups and nation-state actors. Defenders need to monitor for this activity to prevent unauthorized credential access and potential lateral movement within the network. This rule specifically looks for \u0026ldquo;save\u0026rdquo; and \u0026ldquo;export\u0026rdquo; arguments targeting SAM and SECURITY hives.\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 executes \u003ccode\u003ereg.exe\u003c/code\u003e from the command line or through a script.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ereg.exe\u003c/code\u003e command includes arguments to save or export registry hives.\u003c/li\u003e\n\u003cli\u003eThe target registry hives are \u003ccode\u003eHKLM\\SAM\u003c/code\u003e and \u003ccode\u003eHKLM\\SECURITY\u003c/code\u003e, containing sensitive credential information.\u003c/li\u003e\n\u003cli\u003eThe exported registry hive is saved to a file on disk or a network share.\u003c/li\u003e\n\u003cli\u003eThe attacker may compress or encrypt the exported registry hive to evade detection.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the exported registry hive for offline analysis.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts credential information from the registry hive, such as password hashes and LSA secrets, to use in lateral movement or privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to acquire sensitive credentials stored within the registry. This can lead to lateral movement within the network, privilege escalation, and ultimately, data exfiltration or system compromise. Compromised credentials can be used to access critical systems and data, causing significant damage to the organization. The impact is considered high due to the potential for widespread access and control over the compromised environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation auditing with command line arguments to capture the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with relevant arguments. (\u003ca href=\"https://ela.st/audit-process-creation\"\u003eData Source: Windows Security Event Logs, Sysmon\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Registry Hive Export via Reg.exe\u003c/code\u003e to your SIEM to detect the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with arguments indicative of registry hive dumping.\u003c/li\u003e\n\u003cli\u003eImplement access controls and monitor file system activity to detect unauthorized access or modification of registry hive files.\u003c/li\u003e\n\u003cli\u003eReview and restrict the use of \u003ccode\u003ereg.exe\u003c/code\u003e to authorized personnel and processes.\u003c/li\u003e\n\u003cli\u003eMonitor for parent processes of \u003ccode\u003ereg.exe\u003c/code\u003e that are unusual or unexpected, which might indicate malicious activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the process command line, parent process, and destination of the exported registry hive.\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-24-registry-hive-dump/","summary":"Detects attempts to export sensitive Windows registry hives (SAM/SECURITY) using reg.exe, potentially leading to credential compromise.","title":"Credential Acquisition via Registry Hive Dumping","url":"https://feed.craftedsignal.io/briefs/2024-01-24-registry-hive-dump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory","Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["credential-access","privilege-escalation","collection","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies attempts to access sensitive attributes within Active Directory via the Lightweight Directory Access Protocol (LDAP). These attributes, including \u003ccode\u003eunixUserPassword\u003c/code\u003e, \u003ccode\u003ems-PKI-AccountCredentials\u003c/code\u003e, and \u003ccode\u003emsPKI-CredentialRoamingTokens\u003c/code\u003e, are valuable targets for adversaries aiming to steal credentials or escalate privileges. The rule focuses on Windows Security Event Logs, specifically monitoring event code 4662 which indicates an attempt to access an object. By filtering out common benign access patterns, such as those originating from the SYSTEM account or using specific access masks, the rule aims to highlight potentially malicious activity that warrants further investigation. The original rule was created in November 2022 and updated in May 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 within the target domain (e.g., through phishing or exploiting a public-facing application).\u003c/li\u003e\n\u003cli\u003eThe attacker uses valid credentials or exploits a vulnerability to authenticate to the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker uses LDAP queries to enumerate Active Directory objects.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts specific LDAP queries to target sensitive attributes like \u003ccode\u003eunixUserPassword\u003c/code\u003e, \u003ccode\u003ems-PKI-AccountCredentials\u003c/code\u003e, or \u003ccode\u003emsPKI-CredentialRoamingTokens\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWindows Security Event 4662 is generated, logging the access attempt with details about the user, accessed object, and properties.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the accessed attribute data, potentially containing password hashes, certificates, or other sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials or certificates to impersonate other users or gain elevated privileges within the domain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the compromise of domain accounts, including privileged accounts. Attackers can use stolen credentials to move laterally within the network, access sensitive data, and disrupt business operations. Depending on the attributes accessed, this could also expose private keys and authentication certificates leading to further attacks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Access to Sensitive LDAP Attributes\u0026rdquo; to your SIEM to detect access attempts to critical AD attributes (rule.name).\u003c/li\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Access\u0026rdquo; to ensure that necessary Windows Security Event Logs (event code 4662) are generated for the Sigma rule to function (setup).\u003c/li\u003e\n\u003cli\u003eReview and tune the \u0026ldquo;Access to Sensitive LDAP Attributes\u0026rdquo; Sigma rule, creating exceptions for legitimate administrative accounts and scheduled system processes to minimize false positives (rule.note).\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and permissions for sensitive LDAP attributes within Active Directory to restrict access to only necessary personnel (rule.note).\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts from the Sigma rule, focusing on identifying the user/process attempting access (winlog.event_data.SubjectUserSid) and the specific sensitive attribute accessed (winlog.event_data.Properties) (rule.note).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-19T16:23:00Z","date_published":"2024-01-19T16:23:00Z","id":"/briefs/2024-01-ldap-attribute-access/","summary":"This rule detects unauthorized access to sensitive Active Directory object attributes such as unixUserPassword, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens, potentially leading to credential theft and privilege escalation.","title":"Detection of Sensitive LDAP Attribute Access","url":"https://feed.craftedsignal.io/briefs/2024-01-ldap-attribute-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["credential-access","brute-force","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule focuses on identifying brute-force or password guessing attacks against Windows systems. It detects multiple failed logon attempts originating from the same source IP address, followed by a successful logon. This pattern suggests an attacker attempting to guess credentials to gain unauthorized access to an account. The rule leverages Windows Security Event Logs to monitor authentication events. This activity is important for defenders because successful brute-force attacks can lead to account compromise, data breaches, and further malicious activities within the network. The rule uses EQL and analyzes \u003ccode\u003elogs-system.security*\u003c/code\u003e, \u003ccode\u003elogs-windows.forwarded*\u003c/code\u003e, and \u003ccode\u003ewinlogbeat-*\u003c/code\u003e indices.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker initiates multiple failed logon attempts to a Windows system using various username and password combinations. These attempts originate from a single source IP address and target network logon types.\u003c/li\u003e\n\u003cli\u003eThe system records each failed logon attempt as a Windows Security Event Log event (Event ID 4625). The event includes information about the source IP address, target username, and failure reason.\u003c/li\u003e\n\u003cli\u003eAfter several failed attempts, the attacker guesses the correct password for a valid user account.\u003c/li\u003e\n\u003cli\u003eThe system records a successful logon event (Event ID 4624) for the compromised account, originating from the same source IP address as the previous failed attempts, also via a network logon type.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the target system using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to escalate privileges or move laterally within the network, using the compromised account to access additional resources or systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful brute-force attack can lead to unauthorized access to sensitive data, system compromise, and further malicious activities within the network. Compromised accounts can be used to escalate privileges, move laterally, and deploy ransomware. The severity depends on the privileges of the compromised account and the sensitivity of the data it can access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon to generate the necessary events (4624, 4625) in the Windows Security Event Logs for the detection rule to function. Reference: \u003ca href=\"https://ela.st/audit-logon\"\u003ehttps://ela.st/audit-logon\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect multiple logon failures followed by a successful logon. Tune the rule based on your environment and baseline activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eConsider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious activity originating from the source IP address associated with the brute-force attempts.\u003c/li\u003e\n\u003cli\u003eReview and enforce strong password policies to reduce the likelihood of successful password guessing.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T14:00:00Z","date_published":"2024-01-09T14:00:00Z","id":"/briefs/2024-01-09-multiple-logon-failure-success/","summary":"This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker may have compromised an account by brute-forcing login attempts across multiple users.","title":"Multiple Logon Failure Followed by Logon Success","url":"https://feed.craftedsignal.io/briefs/2024-01-09-multiple-logon-failure-success/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["MSBuild","Elastic Defend","Sysmon","Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","execution","msbuild"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThe Microsoft Build Engine (MSBuild) is a legitimate tool used for building applications. However, adversaries may abuse MSBuild to execute malicious scripts or compile code, effectively bypassing security controls. This technique is often employed to deploy malicious payloads. This detection focuses on identifying instances where MSBuild initiates unusual processes such as PowerShell, Internet Explorer, or the Visual C# Command Line Compiler (csc.exe). This activity is considered suspicious because legitimate software development workflows do not typically involve MSBuild directly spawning these processes. The original Elastic detection rule was created on 2020-03-25 and 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 a system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or creates an MSBuild project file (.csproj or .sln) containing malicious commands.\u003c/li\u003e\n\u003cli\u003eThe malicious MSBuild project file is crafted to execute a script or compile code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the MSBuild.exe or msbuild.exe utility to execute the malicious project file.\u003c/li\u003e\n\u003cli\u003eMSBuild spawns an unusual process such as powershell.exe, csc.exe, or iexplore.exe based on the malicious project file configuration.\u003c/li\u003e\n\u003cli\u003ePowerShell executes arbitrary commands, downloads further payloads, or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe C# compiler (csc.exe) compiles malicious code into an executable or library.\u003c/li\u003e\n\u003cli\u003eThe compiled malware or downloaded payloads execute, leading to further compromise, 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 lead to arbitrary code execution, allowing attackers to deploy malware, compromise sensitive data, and establish persistence on the targeted system. The use of MSBuild for malicious purposes allows attackers to bypass application whitelisting and other security controls that trust signed Microsoft binaries. While the precise number of victims is unknown, this technique can be employed against a wide range of organizations, particularly those with vulnerable systems or inadequate endpoint protection.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging, specifically including parent-child relationships, to detect unusual process spawning by MSBuild (logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*, winlogbeat-*).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Microsoft Build Engine Started an Unusual Process\u0026rdquo; to your SIEM to identify instances of MSBuild spawning suspicious processes, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of MSBuild spawning PowerShell, csc.exe, or iexplore.exe to determine if the activity is legitimate or malicious (process.name:(\u0026ldquo;csc.exe\u0026rdquo; or \u0026ldquo;iexplore.exe\u0026rdquo; or \u0026ldquo;powershell.exe\u0026rdquo;)).\u003c/li\u003e\n\u003cli\u003eMonitor for modifications to MSBuild project files (.proj or .sln) for signs of tampering.\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-msbuild-unusual-process/","summary":"Adversaries may exploit MSBuild to execute malicious scripts or compile code, bypassing security controls; this rule detects unusual processes initiated by MSBuild, such as PowerShell or C# compiler, signaling potential misuse for executing unauthorized or harmful actions.","title":"MSBuild запускает необычные процессы","url":"https://feed.craftedsignal.io/briefs/2024-01-msbuild-unusual-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["high"],"_cs_tags":["credential-access","ntlm-relay","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies potential NTLM relay attacks targeting computer accounts in Windows environments. The attack involves coercing a target server to authenticate to an attacker-controlled system and then relaying that authentication to another service. It focuses on detecting a sequence of events: initial coercion attempts against specific named pipes known to be vulnerable, followed by authentication attempts using the target server\u0026rsquo;s computer account from a different host. This activity can allow an attacker to gain unauthorized access and execute commands with the privileges of the compromised computer account. The rule leverages Windows Security Event Logs to identify these patterns, providing a mechanism for defenders to detect and respond to NTLM relay attacks. The detection is based on research from 2025/2026 on coerced authentication methods and NTLM reflection techniques.\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 machine within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a coercion attack against a target server, forcing it to authenticate to a malicious endpoint. This often involves leveraging vulnerabilities in services such as Spoolss, Netlogon, or other RPC services. The attacker uses methods outlined in the referenced coercion authentication research.\u003c/li\u003e\n\u003cli\u003eThe target server attempts to access a named pipe on the attacker-controlled system. This is logged as a File Share event (Event ID 5145) on the target server, indicating access to a named pipe like \u003ccode\u003eSpoolss\u003c/code\u003e, \u003ccode\u003enetdfs\u003c/code\u003e, \u003ccode\u003elsarpc\u003c/code\u003e, \u003ccode\u003elsass\u003c/code\u003e, \u003ccode\u003enetlogon\u003c/code\u003e, \u003ccode\u003esamr\u003c/code\u003e, \u003ccode\u003eefsrpc\u003c/code\u003e, \u003ccode\u003eFssagentRpc\u003c/code\u003e, \u003ccode\u003eeventlog\u003c/code\u003e, \u003ccode\u003ewinreg\u003c/code\u003e, \u003ccode\u003esrvsvc\u003c/code\u003e, \u003ccode\u003ednsserver\u003c/code\u003e, or \u003ccode\u003eWinsPipe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLM authentication attempt from the target server.\u003c/li\u003e\n\u003cli\u003eThe attacker relays the captured NTLM authentication to another service on the network, impersonating the target server. The authentication event is logged (Event ID 4624 or 4625), showing a logon attempt using the NTLM protocol and a computer account (username ending in \u0026ldquo;$\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe authentication attempt originates from a different IP address than the target server\u0026rsquo;s IP, indicating the relay.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains unauthorized access to the service and can execute commands or access data with the privileges of the target server\u0026rsquo;s computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised computer account to move laterally within the network, potentially gaining access to sensitive resources or escalating privileges further.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful NTLM relay attack can allow attackers to gain control of critical systems and data. By compromising a computer account, attackers can move laterally within the network, access sensitive information, and potentially disrupt business operations. The number of victims and the extent of the damage can vary depending on the scope of the attacker\u0026rsquo;s activities after compromising the computer account. Organizations in any sector that rely on Windows networks and Active Directory are vulnerable. Failure to detect and prevent these attacks can lead to significant financial losses, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable and monitor Windows Security Event Logs, specifically for Event IDs 5145 (File Share access), 4624 (Successful Logon), and 4625 (Failed Logon), as these are crucial for detecting NTLM relay attempts.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM to detect potential NTLM relay attacks based on the sequence of file access and authentication events.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on the source and target of the authentication events, the named pipes accessed, and any follow-on activity.\u003c/li\u003e\n\u003cli\u003eReview and harden NTLM configuration to mitigate relay attacks, and consider disabling NTLM where possible in favor of more secure authentication protocols like Kerberos.\u003c/li\u003e\n\u003cli\u003eEnable SMB signing and Extended Protection for Authentication to prevent NTLM relay attacks.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit the scope of potential NTLM relay attacks.\u003c/li\u003e\n\u003cli\u003eApply the \u0026ldquo;Setup\u0026rdquo; configurations by enabling the recommended Windows audit policies to ensure the events required by the rules are generated.\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-ntlm-relay-computer-account/","summary":"This rule detects potential NTLM relay attacks against computer accounts by identifying coercion attempts followed by authentication events originating from a different host, indicating that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system.","title":"Potential NTLM Relay Attack against a Computer Account","url":"https://feed.craftedsignal.io/briefs/2024-01-ntlm-relay-computer-account/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["execution","defense-evasion","windows","process-execution"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies instances of process execution originating from suspicious default Windows directories. Attackers often exploit these locations to conceal malware, leveraging the implicit trust associated with system or application paths to evade security measures. This tactic is employed to make malicious executions appear less conspicuous. The rule focuses on detecting specific processes, including \u003ccode\u003ewscript.exe\u003c/code\u003e, \u003ccode\u003ecscript.exe\u003c/code\u003e, \u003ccode\u003erundll32.exe\u003c/code\u003e, \u003ccode\u003eregsvr32.exe\u003c/code\u003e, and others, when they are executed from unusual directories, such as \u003ccode\u003eC:\\\\PerfLogs\\\\\u003c/code\u003e, \u003ccode\u003eC:\\\\Users\\\\Public\\\\\u003c/code\u003e, and \u003ccode\u003eC:\\\\Windows\\\\Tasks\\\\\u003c/code\u003e. The intent is to highlight anomalous process behaviors that deviate from expected norms, providing early warning of potential malicious activity. The detection logic also includes filters to reduce false positives by excluding known legitimate executables and command line arguments from the specified directories.\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 phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads or drops a malicious payload into a suspicious directory like \u003ccode\u003eC:\\\\Users\\\\Public\\\\\u003c/code\u003e or \u003ccode\u003eC:\\\\Windows\\\\Tasks\\\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a legitimate Windows utility such as \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, or \u003ccode\u003ewscript.exe\u003c/code\u003e to execute the malicious payload.\u003c/li\u003e\n\u003cli\u003eThe executed script or binary performs malicious actions, such as establishing persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to evade detection by masquerading the malicious activity as legitimate system processes.\u003c/li\u003e\n\u003cli\u003eThe malware may attempt to communicate with a command-and-control server.\u003c/li\u003e\n\u003cli\u003eThe malware may perform lateral movement within the network.\u003c/li\u003e\n\u003cli\u003eThe final objective of the attacker is to exfiltrate sensitive data or cause damage to the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to malware infection, data compromise, and system instability. Attackers can establish persistent access, escalate privileges, and perform lateral movement within the network. The impact ranges from minor disruptions to significant data breaches depending on the attacker\u0026rsquo;s objectives and the compromised system\u0026rsquo;s role within the organization. The targeted sectors are broad, as this technique is applicable across various industries and organizational sizes.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Execution from Unusual Directory - Command Line\u0026rdquo; to your SIEM and tune for your environment to detect suspicious process executions from unusual directories.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the process execution chain and command-line arguments.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging with command line arguments to provide the necessary data for the Sigma rule (reference log source in rule).\u003c/li\u003e\n\u003cli\u003eRegularly review and update the list of suspicious directories in the Sigma rule to reflect changes in your environment.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to restrict the execution of unauthorized applications from unusual directories.\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-03-execution-from-unusual-directory/","summary":"This rule identifies process execution from suspicious default Windows directories, which adversaries may abuse to hide malware in trusted paths to evade defenses.","title":"Execution from Unusual Directory - Command Line","url":"https://feed.craftedsignal.io/briefs/2024-01-03-execution-from-unusual-directory/"},{"_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","Sysmon","Elastic Defend","Elastic Endpoint Security","CrowdStrike Falcon","SentinelOne Cloud Funnel","Windows Security Event Logs","winlogbeat"],"_cs_severities":["medium"],"_cs_tags":["persistence","execution","windows","wmi"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Crowdstrike","SentinelOne","Elastic"],"content_html":"\u003cp\u003eWindows Management Instrumentation (WMI) provides a powerful framework for managing Windows systems, but adversaries can abuse its capabilities to establish persistence. By creating WMI event subscriptions, attackers can execute arbitrary code in response to defined system events. This technique involves creating event filters, providers, consumers, and bindings that automatically run malicious code. This can be achieved through tools like \u003ccode\u003ewmic.exe\u003c/code\u003e, which allows the creation of event consumers such as \u003ccode\u003eActiveScriptEventConsumer\u003c/code\u003e or \u003ccode\u003eCommandLineEventConsumer\u003c/code\u003e. Successful exploitation of WMI for persistence allows attackers to maintain unauthorized access to a compromised system, even after reboots or other system changes. This activity has been observed across various environments, highlighting the need for robust detection mechanisms to identify and prevent WMI-based 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 Windows system through unspecified means.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ewmic.exe\u003c/code\u003e to create a WMI event filter that defines a specific event to monitor.\u003c/li\u003e\n\u003cli\u003eA WMI event consumer, such as \u003ccode\u003eActiveScriptEventConsumer\u003c/code\u003e or \u003ccode\u003eCommandLineEventConsumer\u003c/code\u003e, is created using \u003ccode\u003ewmic.exe\u003c/code\u003e specifying the malicious code or script to execute when the event occurs.\u003c/li\u003e\n\u003cli\u003eA WMI binding is established between the event filter and the event consumer using \u003ccode\u003ewmic.exe\u003c/code\u003e, linking the event to the action.\u003c/li\u003e\n\u003cli\u003eThe malicious WMI event subscription is activated, monitoring for the defined event.\u003c/li\u003e\n\u003cli\u003eWhen the specified event occurs, the WMI service triggers the execution of the associated malicious code or script through the event consumer.\u003c/li\u003e\n\u003cli\u003eThe attacker gains persistent access to the system, as the WMI event subscription will re-activate after reboots.\u003c/li\u003e\n\u003cli\u003eThe attacker can then perform additional malicious activities, such as lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of WMI for persistence can allow an attacker to maintain long-term, unauthorized access to a compromised system. This can result in data theft, system compromise, and further malicious activities. While the exact number of victims is not specified in the source, the broad applicability of this technique means that many Windows systems are potentially at risk. If the attack succeeds, the attacker gains a foothold on the system that is difficult to detect and remove, which can lead to significant operational disruption and financial loss.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging and monitor for \u003ccode\u003ewmic.exe\u003c/code\u003e with command-line arguments related to creating event consumers, specifically \u003ccode\u003eActiveScriptEventConsumer\u003c/code\u003e or \u003ccode\u003eCommandLineEventConsumer\u003c/code\u003e, to trigger the Sigma rule \u0026ldquo;Detect Suspicious WMIC Process\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious WMI event subscription creation.\u003c/li\u003e\n\u003cli\u003eReview the investigation steps outlined in the provided documentation to triage and analyze potential WMI persistence attempts.\u003c/li\u003e\n\u003cli\u003eMonitor Windows Security Event Logs and Sysmon for events related to WMI activity for broader coverage.\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-wmi-persistence/","summary":"Adversaries can leverage Windows Management Instrumentation (WMI) to establish persistence by creating event subscriptions that trigger malicious code execution when specific events occur, using tools like wmic.exe to create event consumers.","title":"Persistence via WMI Event Subscription","url":"https://feed.craftedsignal.io/briefs/2024-01-wmi-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","windows","audit-policy"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may disable auditing on a system in order to evade detection and forensic analysis. This is often done after initial compromise, to prevent security tools from logging their actions. This rule identifies attempts to disable auditing for specific security-sensitive audit policy sub-categories, providing defenders with insight into potential malicious activity. The rule leverages Windows Security Event Logs and specifically focuses on Event ID 4719, which indicates changes to the audit policy. It aggregates policy changes within 5-minute windows to identify removals of audit policies that are not re-enabled within the same timeframe, reducing false positives from temporary or legitimate policy changes. This detection logic is implemented using ES|QL in Elastic Stack version 9.3.0 and later.\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 system through various means (e.g., phishing, exploitation of vulnerabilities).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates their privileges to gain administrative or system-level access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker performs reconnaissance to identify the current audit policy settings and determine which sub-categories are enabled.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker executes commands or scripts to disable specific audit policy sub-categories, such as Logon, Audit Policy Change, Process Creation, Other System Events, Security Group Management, and User Account Management, using tools like \u003ccode\u003eauditpol.exe\u003c/code\u003e or modifying Group Policy Objects.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eActivity Execution:\u003c/strong\u003e With auditing disabled, the attacker performs malicious activities without generating relevant security logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence mechanisms to maintain access to the system, such as creating scheduled tasks or modifying registry keys.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally to other systems on the network, potentially disabling auditing on those systems as well.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eObjective Completion:\u003c/strong\u003e The attacker achieves their objective, which could include data theft, system disruption, or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of audit policies can severely impair an organization\u0026rsquo;s ability to detect and respond to security incidents. Without proper logging, malicious activities can go unnoticed, leading to prolonged compromises and increased damage. Disabling auditing can impact incident response efforts, making it difficult to determine the scope and impact of an attack. The risk score associated with this activity is 47, indicating a significant potential impact on security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Policy Change auditing to generate the necessary events for this rule as described in the \u003ca href=\"https://ela.st/audit-policy-change\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect attempts to disable sensitive audit policy sub-categories. Tune the rule as necessary based on your environment and baseline activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the audit policy changes and identify potential malicious activity.\u003c/li\u003e\n\u003cli\u003eReview the \u003ca href=\"https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4719\"\u003ereferences\u003c/a\u003e to understand the significance of Event ID 4719 and its implications for security monitoring.\u003c/li\u003e\n\u003cli\u003eConsider enabling Sysmon process creation logging with command line auditing to detect the use of tools such as \u003ccode\u003eauditpol.exe\u003c/code\u003e to modify audit policies.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-audit-policy-disabled/","summary":"This rule identifies attempts to disable auditing for security-sensitive audit policy sub-categories on Windows systems, often employed by attackers to evade detection and forensic analysis.","title":"Windows Audit Policy Sub-Category Disabled","url":"https://feed.craftedsignal.io/briefs/2024-01-audit-policy-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["credential-access","brute-force","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule, originally created on 2020-08-29 and last updated on 2026-05-04, identifies potential brute-force attempts against Windows systems. It focuses on scenarios where an attacker attempts to guess passwords for multiple accounts containing the term \u0026ldquo;admin\u0026rdquo; in their usernames, suggesting an attempt to compromise privileged accounts. The rule aggregates failed logon events to detect this activity. This is important for defenders as successful brute-force attacks can lead to unauthorized access, data breaches, and other malicious activities. The rule leverages Windows Security Event Logs and requires Audit Logon to be enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker attempts to gain initial access to the target network.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies potential target accounts with \u0026ldquo;admin\u0026rdquo; in their username.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a series of network logon attempts using various password combinations (T1110.001, T1110.003).\u003c/li\u003e\n\u003cli\u003eThe Windows system records failed logon events (Event ID 4625) in the Security Event Logs.\u003c/li\u003e\n\u003cli\u003eThe detection rule aggregates these failed logon events, filtering out known noisy failure codes.\u003c/li\u003e\n\u003cli\u003eIf the number of failed attempts against distinct \u0026ldquo;admin\u0026rdquo; accounts from the same source IP within a 60-second window exceeds a threshold (50 attempts against 2 distinct usernames), the rule triggers an alert.\u003c/li\u003e\n\u003cli\u003eThe attacker, if successful, gains unauthorized access to the targeted admin account.\u003c/li\u003e\n\u003cli\u003eWith access to an admin account, the attacker can perform a wide range of malicious activities, including privilege escalation, data exfiltration, and system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful brute-force attacks on administrator accounts can lead to significant damage. Attackers gaining access can escalate privileges, install malware, access sensitive data, or disrupt critical systems. This can result in data breaches, financial losses, and reputational damage. While specific victim counts are not provided, the rule\u0026rsquo;s focus on privileged accounts indicates a high potential for severe impact on organizations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon to generate the necessary Windows Security Event Logs. Refer to the setup instructions at \u003ca href=\"https://ela.st/audit-logon\"\u003ehttps://ela.st/audit-logon\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Windows Admin Account Brute Force\u0026rdquo; to your SIEM and tune the threshold parameters (failed_auth_count, count_distinct_user_name) for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the Sigma rule, focusing on the source IP address, targeted usernames, and logon failure reason codes.\u003c/li\u003e\n\u003cli\u003eReview and strengthen password policies to prevent password guessing attacks (T1110).\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious logon attempts from external IP addresses to internal systems.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-admin-account-bruteforce/","summary":"This rule identifies potential password guessing/brute force activity from a single source IP targeting multiple Windows accounts with 'admin' in the username, indicating an attempt to compromise privileged accounts.","title":"Windows Admin Account Brute Force Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-admin-account-bruteforce/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","Windows Security Event Logs"],"_cs_severities":["low"],"_cs_tags":["privilege-escalation","defense-evasion","execution","windows","service-creation"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft"],"content_html":"\u003cp\u003eThis detection identifies instances where the Service Control utility (sc.exe) is executed from within a script interpreter, such as cmd.exe, PowerShell, or wscript.exe. Attackers may leverage this behavior to create, modify, or start Windows services, often with the intent to elevate privileges or establish persistence on a compromised system. The sc.exe is a legitimate Windows command-line tool used for managing services. Abusing this tool allows attackers to perform malicious actions under the guise of legitimate system administration. This detection is designed to identify anomalous use of sc.exe that deviates from typical administrative tasks, focusing on instances where it\u0026rsquo;s spawned from scripting environments often used for malicious activities. The rule specifically excludes service creations performed by the SYSTEM user.\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 via an exploit or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script interpreter (e.g., cmd.exe, powershell.exe).\u003c/li\u003e\n\u003cli\u003eWithin the script interpreter, the attacker uses sc.exe to manage Windows services.\u003c/li\u003e\n\u003cli\u003eThe sc.exe command is used with arguments such as \u0026ldquo;create\u0026rdquo;, \u0026ldquo;start\u0026rdquo;, \u0026ldquo;stop\u0026rdquo;, \u0026ldquo;delete\u0026rdquo;, or \u0026ldquo;config\u0026rdquo; to manipulate service configurations.\u003c/li\u003e\n\u003cli\u003eA new service is created or an existing service is modified to execute a malicious payload.\u003c/li\u003e\n\u003cli\u003eThe malicious service is started, allowing the attacker to execute code with elevated privileges (SYSTEM).\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by ensuring the malicious service automatically starts upon system reboot.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the created service to execute additional malicious commands or maintain remote access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to complete system compromise with the attacker gaining SYSTEM level privileges. This can allow for lateral movement within the network, data exfiltration, or installation of persistent backdoors. While the frequency of this specific technique may be low, the potential impact is high due to the elevated privileges gained.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eService Control Spawning via Script Interpreter\u003c/code\u003e to your SIEM to detect this specific behavior and tune it to your environment.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for sc.exe being executed by script interpreters like PowerShell or cmd.exe (as covered in the rule description).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of sc.exe being used with the arguments \u0026ldquo;create\u0026rdquo;, \u0026ldquo;start\u0026rdquo;, \u0026ldquo;stop\u0026rdquo;, \u0026ldquo;delete\u0026rdquo;, or \u0026ldquo;config\u0026rdquo; from scripting environments to identify potentially malicious activity.\u003c/li\u003e\n\u003cli\u003eEnsure proper access controls are in place to limit the ability of users to create or modify services.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-service-control-script-spawn/","summary":"Detection of Service Control (sc.exe) being spawned from script interpreter processes, such as PowerShell or cmd.exe, to create, modify, or start services, which may indicate privilege escalation or persistence attempts by an attacker.","title":"Service Control Executed from Script Interpreters","url":"https://feed.craftedsignal.io/briefs/2024-01-02-service-control-script-spawn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs","HPDeviceCheck","HP Support Assistant","HP Web Products Detection","Microsoft Visual Studio","OneDrive","Firefox","Office","Windows GroupPolicy"],"_cs_severities":["medium"],"_cs_tags":["persistence","scheduled_task","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Hewlett-Packard","Microsoft","Google","Mozilla"],"content_html":"\u003cp\u003eAdversaries frequently abuse Windows scheduled tasks to establish persistence, move laterally within a network, and escalate privileges. This technique involves creating or modifying scheduled tasks to execute malicious code at specific times or in response to certain events. This detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. The rule relies on Windows Security Event Logs, offering a valuable method for identifying unauthorized task creation indicative of malicious activity. The detection logic specifically excludes common tasks associated with software updates from vendors like Hewlett-Packard, Microsoft, Google, and Mozilla, as well as tasks run by system 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 a system, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses their initial access to execute commands, potentially leveraging PowerShell or cmd.exe.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eschtasks\u003c/code\u003e command-line utility or the COM interface to create a new scheduled task.\u003c/li\u003e\n\u003cli\u003eThe scheduled task is configured to execute a malicious payload, such as a reverse shell or a data exfiltration script.\u003c/li\u003e\n\u003cli\u003eThe task is set to trigger based on a specific schedule, such as at system startup, at a specific time, or upon a specific event.\u003c/li\u003e\n\u003cli\u003eWhen the trigger occurs, the scheduled task executes the malicious payload.\u003c/li\u003e\n\u003cli\u003eThe malicious payload establishes persistence, allowing the attacker to maintain access to the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker can then use the persistent access to move laterally to other systems or to exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows adversaries to maintain persistent access to compromised systems, potentially leading to data theft, system disruption, or further lateral movement within the network. By creating malicious scheduled tasks, attackers can ensure their code is executed even after a system reboot or user logoff. This can result in long-term compromise and significant damage to affected organizations. While the number of victims and specific sectors targeted are not detailed, the potential impact is broad due to the widespread use of Windows systems in enterprise environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Security Event Logging and ensure that event ID 4698 (A scheduled task was created) is collected.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Scheduled Task Creation via Winlog\u0026rdquo; to your SIEM to detect potentially malicious scheduled task creation events.\u003c/li\u003e\n\u003cli\u003eRegularly review and update the exclusion list in the Sigma rule to account for new benign scheduled tasks in your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the task\u0026rsquo;s name, path, actions, and triggers to determine if they are suspicious.\u003c/li\u003e\n\u003cli\u003eMonitor for related suspicious activity, such as unusual process executions or network connections originating from the compromised system.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-scheduled-task-creation/","summary":"This rule detects the creation of scheduled tasks in Windows using event logs, which adversaries may use for persistence, lateral movement, or privilege escalation by creating malicious tasks.","title":"Detecting Suspicious Scheduled Task Creation in Windows","url":"https://feed.craftedsignal.io/briefs/2024-01-scheduled-task-creation/"}],"language":"en","title":"CraftedSignal Threat Feed — Windows Security Event Logs","version":"https://jsonfeed.org/version/1.1"}