{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/threat-detection/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["lateral-movement","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003ePass-the-Hash (PtH) is a technique where attackers leverage stolen password hashes to authenticate and move laterally within a Windows environment, bypassing standard system access controls. Instead of needing the plaintext password, adversaries use a hash of the password to authenticate to a remote service or server. This detection rule focuses on identifying potential PtH attempts by monitoring for successful logins using specific user IDs (S-1-5-21-* or S-1-12-1-*) and the \u003ccode\u003eseclogo\u003c/code\u003e logon process, which is commonly associated with credential theft and misuse. The rule aims to detect anomalous authentication patterns indicating that an attacker is using PtH to gain unauthorized access to systems. This is important because successful PtH attacks can lead to widespread compromise of sensitive data and critical infrastructure.\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 phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker dumps password hashes from the compromised system using tools like Mimikatz.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target system within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen password hash to authenticate to the target system using the \u003ccode\u003eseclogo\u003c/code\u003e logon process.\u003c/li\u003e\n\u003cli\u003eWindows validates the hash, granting the attacker access without requiring the plaintext password.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully authenticates with the stolen credentials and a user ID matching the pattern S-1-5-21-* or S-1-12-1-*.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages their unauthorized access to move laterally to other systems or access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, 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 Pass-the-Hash attacks can lead to significant damage, including unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Organizations can experience financial losses, reputational damage, and operational disruptions. While the specific number of victims is not stated, PtH is a common technique used in many breaches, potentially affecting any organization that relies on Windows authentication.\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 as referenced in the setup instructions \u003ca href=\"https://ela.st/audit-logon\"\u003ehttps://ela.st/audit-logon\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to your SIEM to detect potential Pass-the-Hash attempts. Tune the rule to account for legitimate uses of the \u003ccode\u003eseclogo\u003c/code\u003e logon process.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on correlating the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems.\u003c/li\u003e\n\u003cli\u003eReview and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege after an incident, as detailed in the Response and Remediation section.\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-potential-pth/","summary":"This rule detects potential Pass-the-Hash (PtH) attempts in Windows environments by monitoring successful authentications with specific user IDs (S-1-5-21-* or S-1-12-1-*) and the `seclogo` logon process, where attackers use stolen password hashes to authenticate and move laterally across systems without needing plaintext passwords.","title":"Potential Pass-the-Hash (PtH) Attempt Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-potential-pth/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["credential-access","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies potential NTLM relay attacks targeting Windows computer accounts. The rule focuses on authentication events where a computer account (identified by a name ending in \u0026lsquo;$\u0026rsquo;) is used for network logon from an IP address that does not match the IP address of the host owning the account. Such activity can indicate that an attacker has captured the computer account\u0026rsquo;s NTLM hash through forced authentication techniques and is relaying it from a different machine to gain unauthorized access to resources. The rule is designed to detect activity within the last 9 months and relies on Windows Security Event Logs for analysis.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the network through various means (e.g., phishing, exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a forced authentication attack (T1187) to coerce a target machine to authenticate to a system under the attacker\u0026rsquo;s control.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLM hash of a computer account, which is automatically generated for every machine joined to the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the captured NTLM hash to relay authentication requests to other systems on the network. This leverages the \u0026ldquo;Adversary-in-the-Middle\u0026rdquo; technique (T1557), specifically \u0026ldquo;LLMNR/NBT-NS Poisoning and SMB Relay\u0026rdquo; (T1557.001).\u003c/li\u003e\n\u003cli\u003eThe relay attack manifests as a network logon event (event code 4624 or 4625) where the source IP address does not match the IP address of the host that owns the computer account. The AuthenticationPackageName is NTLM.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to resources or performs actions on behalf of the compromised computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt lateral movement, privilege escalation, or data exfiltration depending on the targeted resource.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful NTLM relay attacks against computer accounts can grant attackers unauthorized access to critical systems and data within the Windows domain. This could lead to privilege escalation, lateral movement, and ultimately, compromise of the entire domain. While the exact number of affected organizations is unknown, any organization relying on NTLM authentication and Active Directory is potentially vulnerable. The impact includes data breaches, system compromise, and significant disruption to business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon in Windows to generate the necessary security events for this rule to function, as described in the provided setup instructions.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule below to your SIEM to detect potential computer account relay activity and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by comparing the source.ip to the target server host.ip addresses to confirm it\u0026rsquo;s indeed a remote use of the machine account.\u003c/li\u003e\n\u003cli\u003eStrengthen network segmentation to limit the attack surface for credential relay attacks, as recommended in the remediation steps.\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous authentication patterns and NTLM-related activity to identify and respond to potential relay attacks.\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-computer-account-relay/","summary":"Detection of potential NTLM relay attacks targeting computer accounts by identifying authentication events originating from hosts other than the account's owner, indicating possible credential theft and misuse.","title":"Potential Computer Account NTLM Relay Activity","url":"https://feed.craftedsignal.io/briefs/2024-07-computer-account-relay/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Cortex XDR","Cortex XSIAM","Unit 42 Frontier AI Defense","Prisma Cloud","Cortex XSOAR","Cortex Xpanse","Prisma SASE","Prisma Access","Prisma SD-WAN"],"_cs_severities":["high"],"_cs_tags":["cloud-security","iam","incident-response","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Palo Alto Networks"],"content_html":"\u003cp\u003eThe 2026 Unit 42 Global Incident Response Report highlights that threat actors are moving 4x faster to exfiltration than in 2025, exploiting blind spots due to an over-reliance on endpoint data. The proliferation of cloud services, microservices, and remote users has expanded the attack surface beyond what any single tool can monitor. Unit 42 found that in 75% of incidents, critical evidence was present in logs but wasn\u0026rsquo;t accessible or operationalized, allowing attackers to exploit the gaps. Organizations need to evolve their SOCs to ingest and correlate telemetry across their entire IT landscape, including IAM, cloud assets, OT/IoT, and AI workloads. Unit 42 recommends a single-pane-of-glass strategy powered by an AI-driven SOC platform like Cortex XSIAM to combat these threats.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access via Cloud Misconfiguration:\u003c/strong\u003e The attacker gains initial access through a misconfigured cloud service access key.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCloud Console Manipulation:\u003c/strong\u003e The attacker manipulates the cloud console to hide their tracks from endpoint detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePivot to Cloud-Hosted Server:\u003c/strong\u003e From the cloud console, the attacker pivots to a cloud-hosted server to begin discovery.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Theft (Covert C2):\u003c/strong\u003e The attacker utilizes DNS tunneling to a cloud storage location for C2 communication and steals credentials to use legitimate applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally using the stolen credentials, triggering impossible travel alerts across SaaS apps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRogue Asset Introduction:\u003c/strong\u003e The attacker introduces a rogue device into the network, bypassing traditional endpoint security measures.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistence through the rogue device, using it for covert movement and access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker exfiltrates sensitive data, taking advantage of the gaps in security visibility.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eOrganizations are increasingly vulnerable to rapid data exfiltration due to the expanded attack surface and reliance on endpoint-centric security. The inability to correlate telemetry across diverse IT zones allows attackers to operate undetected, leading to significant data breaches, financial losses, and reputational damage. Unit 42\u0026rsquo;s research shows that attackers are moving 4x faster to exfiltration, exacerbating the impact of successful intrusions. The attacks target cloud environments, identity systems, and networks, creating a complex threat landscape for security teams to navigate.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eIngest and correlate telemetry from all IT zones (IAM, cloud, OT/IoT, AI workloads) into a single repository, as described in the overview, to eliminate data silos and gain holistic visibility.\u003c/li\u003e\n\u003cli\u003eImplement User and Entity Behavior Analytics (UEBA) as mentioned in the overview, to detect anomalous behavior indicative of compromised credentials by using a centralized workbench.\u003c/li\u003e\n\u003cli\u003eDeploy Cortex XSIAM, as discussed in the overview, to leverage AI-driven alert stitching, ML-based incident scoring, and UEBA for automated detection, investigation, and response.\u003c/li\u003e\n\u003cli\u003eImplement continuous network monitoring and external attack surface management to detect and manage rogue assets, as highlighted in the attack chain.\u003c/li\u003e\n\u003cli\u003eEvaluate your current visibility through a formal assessment as recommended in the conclusion, to identify gaps in security coverage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T23:13:22Z","date_published":"2026-05-01T23:13:22Z","id":"/briefs/2026-06-detection-beyond-endpoint/","summary":"Threat actors are rapidly exfiltrating data by exploiting blind spots created by an over-reliance on endpoint data, necessitating a comprehensive security approach that incorporates cloud, identity, and network telemetry for effective threat detection and response.","title":"Expanding Detection Beyond Endpoints to Counter Evolving Threats","url":"https://feed.craftedsignal.io/briefs/2026-06-detection-beyond-endpoint/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["threat-detection","higher-order-rule","elastic-defend"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis Elastic Defend rule is designed to detect potentially compromised hosts by identifying those that trigger multiple distinct and rare behavior rules. The rule leverages Elastic\u0026rsquo;s ESQL to analyze endpoint alerts, focusing on behavior rules that are observed on only a single host globally within a specified lookback window. This approach filters out common or widely triggered rules, reducing false positives and highlighting truly anomalous behavior. The rule aims to pinpoint hosts exhibiting unusual activity patterns that may indicate malicious actions, warranting immediate investigation and response. This detection method became generally available in Elastic Stack version 9.3.0.\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 through an unknown vector.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker attempts to elevate privileges on the compromised host.\u003c/li\u003e\n\u003cli\u003eExecution: The attacker executes malicious code or commands via a script or binary.\u003c/li\u003e\n\u003cli\u003eDefense Evasion: The attacker attempts to evade detection by disabling security tools or masking their activities.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker attempts to move laterally to other systems on the network.\u003c/li\u003e\n\u003cli\u003eCommand and Control: The attacker establishes a command and control channel to communicate with a remote server.\u003c/li\u003e\n\u003cli\u003eCollection: The attacker gathers sensitive data from the compromised host or network.\u003c/li\u003e\n\u003cli\u003eImpact: The attacker achieves their final objective, which could include data exfiltration, system disruption, or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to significant data breaches, system compromise, and operational disruption. The targeted sectors are broad, as the rule is designed to detect general anomalous behavior. Depending on the attacker\u0026rsquo;s objectives, the impact could range from data theft and financial loss to complete system shutdown and reputational damage. Hosts identified by this rule should be considered high-priority candidates for incident response and further investigation. The number of victims is dependent on the scope of the intrusion, but this detection aims to limit the spread of the attack by identifying compromised hosts early.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided ESQL rule to your Elastic environment (min. version 9.3.0) to detect hosts triggering multiple rare behavior alerts as indicated by the rule_id \u003ccode\u003ec4f7a2b1-5d8e-4c3a-9b6e-2f1a0d8c7e5b\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any hosts flagged by this rule, reviewing the associated behavior rule names and process command lines to understand the triggering actions as documented in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eExamine endpoint and network data for the affected host to assess the scope of the compromise and potential persistence mechanisms, per the investigation guidance in the \u003ccode\u003enote\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDocument and exclude known-good rule names or hosts from the detection if legitimate single-host tools or scripts trigger multiple rare behavior rules as described in the \u003ccode\u003enote\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable Elastic Defend on all endpoints to ensure the availability of the required \u003ccode\u003eendpoint.alerts\u003c/code\u003e data source.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-multiple-rare-defend-rules/","summary":"This rule identifies hosts triggering multiple distinct, globally rare Elastic Defend behavior rules, increasing the likelihood of detecting compromised hosts while reducing false positives.","title":"Multiple Rare Elastic Defend Behavior Rules Triggered on Single Host","url":"https://feed.craftedsignal.io/briefs/2026-04-multiple-rare-defend-rules/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["threat-detection","edr","endpoint"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies hosts triggering multiple alerts from external Endpoint Detection and Response (EDR) solutions, indicating a potential compromise. It aggregates alert data from sources such as CrowdStrike, SentinelOne, and Microsoft 365 Defender to identify hosts exhibiting a high volume or diversity of security alerts. The rule aims to detect coordinated attacks across multiple hosts, warranting prioritized investigation and response. It prioritizes hosts that trigger a specific threshold of unique alert rules, different alert severities, or have repetitive patterns involving file paths, command lines, or processes. This approach allows security analysts to focus on systems with a higher likelihood of compromise, reducing the time to detect and respond to potential threats.\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 host through various means, such as exploiting a vulnerability or using stolen credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMalware Deployment:\u003c/strong\u003e The attacker deploys malware onto the compromised host. This could be achieved through techniques like phishing or exploiting software vulnerabilities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExecution:\u003c/strong\u003e The malware executes on the host, initiating malicious activities. This may involve running malicious scripts or binaries.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The malware establishes persistence on the host to maintain access even after a reboot. This can be achieved by creating scheduled tasks or modifying registry keys.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker attempts to move laterally to other hosts on the network. This can involve using techniques like pass-the-hash or exploiting network vulnerabilities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommand and Control:\u003c/strong\u003e The malware establishes communication with a command and control (C2) server to receive instructions and exfiltrate data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to escalate privileges to gain higher-level access to the system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objective, such as stealing sensitive data or disrupting system operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack resulting in multiple EDR alerts can lead to significant disruption and data loss. Depending on the attacker\u0026rsquo;s objectives, this could include the exfiltration of sensitive data, ransomware deployment, or system downtime. The compromise of multiple hosts can indicate a widespread and coordinated attack, potentially affecting a large number of users and systems. Organizations may experience financial losses due to incident response costs, legal liabilities, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eMultiple External EDR Alerts by Host\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable logging for CrowdStrike, SentinelOne, and M365 Defender to ensure the Sigma rule can ingest the appropriate logs, as outlined in the rule\u0026rsquo;s query.\u003c/li\u003e\n\u003cli\u003ePrioritize investigation of hosts identified by the rule with high alert counts or diverse alert severities to minimize potential damage.\u003c/li\u003e\n\u003cli\u003eReview and exclude known benign activities from triggering the rule, as detailed in the false positive analysis section of the rule documentation.\u003c/li\u003e\n\u003cli\u003eCorrelate alert data with other logs (process creation, network connections, file modifications) to provide better context for detected hosts.\u003c/li\u003e\n\u003cli\u003eBlock the C2 domains/IP addresses if they are found to be related to the alerts from the affected hosts.\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-01-multiple-edr-alerts/","summary":"This rule detects multiple external EDR alerts on the same host, indicating a potential compromise, by analyzing alert data from various EDR solutions like CrowdStrike, SentinelOne, and M365 Defender to identify hosts triggering multiple alerts, enabling prioritization of investigation and response.","title":"Multiple External EDR Alerts by Host","url":"https://feed.craftedsignal.io/briefs/2024-01-multiple-edr-alerts/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["email-security","threat-detection","imap"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA security-conscious individual has developed a self-hosted email threat detection tool, \u0026ldquo;VerdictMail,\u0026rdquo; designed to enhance email security through real-time analysis and machine learning. Released in March 2026, the tool leverages IMAP IDLE to monitor incoming emails. VerdictMail then performs a series of enrichment steps, including SPF, DKIM, and DMARC validation to verify sender authenticity. DNSBL lookups identify potential spam sources, while WHOIS queries provide registrant information. Additionally, the tool integrates with URLhaus and VirusTotal to assess the reputation of embedded URLs and attachments. Finally, VerdictMail employs a provider-agnostic Large Language Model (LLM) to render a final verdict on the email\u0026rsquo;s threat level, providing a comprehensive security layer for personal or small-scale email infrastructure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003cp\u003eThis tool is a defensive measure, not an attack. The below steps describe how the tool functions to analyze potential attacks.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eEmail Reception:\u003c/strong\u003e VerdictMail monitors a designated IMAP mailbox using the IMAP IDLE protocol for real-time email arrival.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHeader Analysis:\u003c/strong\u003e Upon receiving a new email, the tool extracts relevant headers, including Sender, From, Reply-To, and Message-ID.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Checks:\u003c/strong\u003e VerdictMail performs SPF, DKIM, and DMARC checks to validate the sender\u0026rsquo;s authenticity and domain reputation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReputation Lookups:\u003c/strong\u003e The tool queries DNSBLs (DNS Blacklists) to identify known spam sources and malicious IPs associated with the sender.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWHOIS Enrichment:\u003c/strong\u003e WHOIS lookups are conducted on the sender\u0026rsquo;s domain to gather registrant information and assess the domain\u0026rsquo;s legitimacy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eURL and Attachment Scanning:\u003c/strong\u003e URLs within the email body are extracted and checked against URLhaus for known malicious URLs. Attachments are submitted to VirusTotal for malware scanning.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLLM Verdict Generation:\u003c/strong\u003e All gathered data is fed into a provider-agnostic Large Language Model (LLM), which analyzes the information and generates a threat verdict.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAlerting/Quarantine:\u003c/strong\u003e Based on the LLM\u0026rsquo;s verdict, VerdictMail can flag the email as suspicious, quarantine it, or generate an alert for further investigation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eVerdictMail aims to reduce the risk of successful phishing attacks, malware infections, and business email compromise (BEC). By automatically analyzing emails and providing a threat verdict, it helps users identify and avoid potentially harmful messages. While the exact number of users is unknown, the tool could prevent financial losses, data breaches, and reputational damage for individuals and small organizations adopting it.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eConsider implementing similar multi-stage enrichment techniques in existing email security solutions by incorporating SPF, DKIM, and DMARC validation (Attack Chain Step 3).\u003c/li\u003e\n\u003cli\u003eIntegrate threat intelligence feeds like URLhaus (Attack Chain Step 6) and VirusTotal (Attack Chain Step 6) into email security workflows to identify malicious URLs and attachments.\u003c/li\u003e\n\u003cli\u003eExplore using LLMs for email threat assessment as an additional layer of security (Attack Chain Step 7).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-18T10:00:00Z","date_published":"2026-03-18T10:00:00Z","id":"/briefs/2026-03-verdictmail/","summary":"A user created a self-hosted email threat detection tool, named VerdictMail, employing IMAP IDLE for real-time monitoring and multi-stage enrichment via SPF, DKIM, DMARC, DNSBL, WHOIS, URLhaus, and VirusTotal, coupled with an LLM for threat assessment.","title":"Self-Hosted Email Threat Detection Tool","url":"https://feed.craftedsignal.io/briefs/2026-03-verdictmail/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["threat-detection","higher-order-rule"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule, created by Elastic, is designed to identify potentially compromised hosts by aggregating alert data. It focuses on scenarios where a single host triggers multiple alerts associated with different phases of an attack, as defined by the ATT\u0026amp;CK framework. The rule calculates a risk score based on the number and severity of alerts, prioritizing hosts exceeding a defined threshold. By focusing on hosts exhibiting diverse attack tactics, analysts can more effectively triage and respond to complex, multi-stage intrusions. This rule helps filter out noisy alerts such as \u0026ldquo;Agent Spoofing\u0026rdquo;, \u0026ldquo;Compression DLL Loaded by Unusual Process\u0026rdquo;, and \u0026ldquo;Potential PrintNightmare File Modification\u0026rdquo;, and focuses on alerts where \u003ccode\u003ekibana.alert.risk_score\u003c/code\u003e is greater than 0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn adversary gains initial access to a host through various methods.\u003c/li\u003e\n\u003cli\u003eThe adversary executes malicious code or commands on the host.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence to maintain access.\u003c/li\u003e\n\u003cli\u003eThe adversary attempts to escalate privileges to gain higher-level control.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement to compromise other systems.\u003c/li\u003e\n\u003cli\u003eThe adversary gathers information about the compromised environment.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data from the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data theft or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack, as identified by this rule, can lead to significant data breaches, system compromise, and operational disruption. Multiple alerts across various tactics suggest a sophisticated and persistent attacker. Prioritizing hosts identified by this rule enables security teams to quickly contain and remediate advanced threats, minimizing potential damage and reducing the overall impact on the organization. Without this detection, analysts might miss critical correlations between seemingly isolated alerts.\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 identify potentially compromised hosts based on multiple alerts across different ATT\u0026amp;CK tactics.\u003c/li\u003e\n\u003cli\u003eInvestigate any hosts flagged by this rule, correlating the alert data with other logs and telemetry to understand the full scope of the attack.\u003c/li\u003e\n\u003cli\u003eTune the threshold values in the Sigma rule (distinct rule count, tactic count, risk score) to align with your environment and risk tolerance.\u003c/li\u003e\n\u003cli\u003eEnable logging for process creation, network connections, and file modifications on all hosts to provide sufficient data for the detection rule.\u003c/li\u003e\n\u003cli\u003eReview the \u0026ldquo;False positive analysis\u0026rdquo; section of the rule\u0026rsquo;s documentation to identify and exclude known benign activities that may trigger the rule.\u003c/li\u003e\n\u003cli\u003eUse the \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e field in the rule output to quickly identify the specific alert types triggering the rule.\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-multiple-alerts-risky-host/","summary":"This rule uses alert data to identify hosts with multiple alerts across different ATT\u0026CK tactics, indicating a higher likelihood of compromise and enabling analysts to prioritize triage and response based on accumulated risk score.","title":"Multiple Alerts in Different ATT\u0026CK Tactics by Host","url":"https://feed.craftedsignal.io/briefs/2024-01-multiple-alerts-risky-host/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Security"],"_cs_severities":["high"],"_cs_tags":["threat-detection","higher-order-rule"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule, sourced from Elastic\u0026rsquo;s detection ruleset, is designed to identify potential user account compromises by aggregating and analyzing existing alert data. The rule focuses on scenarios where a single user triggers multiple distinct alerts, suggesting a higher likelihood of malicious activity. By excluding low-severity alerts and known system accounts, the rule aims to minimize false positives and prioritize investigations. This approach is particularly useful in environments where attackers may attempt to blend in with normal user activity while escalating privileges or moving laterally within the network. The rule utilizes esql to correlate alerts based on user ID. The rule was last updated on 2026/04/27.\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 account, potentially through phishing, credential stuffing, or other methods.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges within the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities, such as discovering sensitive files or network shares.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally to other systems within the network using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses sensitive data, potentially exfiltrating it from the network.\u003c/li\u003e\n\u003cli\u003eThese actions trigger various security alerts related to privilege escalation, lateral movement, and data access.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;Multiple Alerts Involving a User\u0026rdquo; rule detects the correlation between these alerts based on the user ID.\u003c/li\u003e\n\u003cli\u003eSecurity analysts are alerted to investigate the compromised user account and contain the potential damage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging a compromised user account can lead to significant data breaches, financial losses, and reputational damage. The impact can range from unauthorized access to sensitive data to the complete takeover of critical systems. By identifying compromised user accounts early, organizations can mitigate the potential damage and prevent further escalation of the attack. This detection rule helps prioritize investigations and ensures that security analysts focus on the most critical threats.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eMultiple Alerts Involving a User\u003c/code\u003e to your SIEM to detect potential user account compromises based on correlated alerts.\u003c/li\u003e\n\u003cli\u003eEnable audit logging on systems to capture user activity and generate alerts for suspicious actions.\u003c/li\u003e\n\u003cli\u003eReview and tune the threshold values (e.g., distinct alert count) in the Sigma rule to align with your environment and risk tolerance.\u003c/li\u003e\n\u003cli\u003eUse the \u003ccode\u003eResources: Investigation Guide\u003c/code\u003e tag to access guidance on investigating triggered alerts and identifying compromised user accounts.\u003c/li\u003e\n\u003cli\u003eImplement role-based access control (RBAC) to minimize the impact of compromised accounts by limiting access to sensitive resources.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-24T10:00:00Z","date_published":"2024-01-24T10:00:00Z","id":"/briefs/2024-01-24-multiple-alerts-user/","summary":"This rule identifies when multiple different alerts involving the same user are triggered, which could indicate a compromised user account and requires further investigation.","title":"Multiple Alerts Involving a User Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-24-multiple-alerts-user/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["lateral-movement","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies potential lateral movement by flagging spikes in the number of processes initiated during a single RDP session. The rule, based on an Elastic machine learning job named \u003ccode\u003elmd_high_sum_rdp_number_of_processes_ea\u003c/code\u003e, aims to uncover suspicious remote activity indicative of an attacker attempting to execute commands or deploy tools on a compromised host. This detection matters because RDP is a common vector for attackers to gain access to internal networks and subsequently move laterally. The detection leverages Windows RDP process events and file events collected by the Elastic Defend integration. Identifying anomalous process creation within RDP sessions can help defenders identify and respond to potential security incidents faster.\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 network.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages valid credentials or exploits an RDP vulnerability to establish a remote session (T1021.001).\u003c/li\u003e\n\u003cli\u003eOnce connected via RDP, the attacker begins to execute a series of commands to enumerate the system and network.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to install malware or other malicious tools, triggering the creation of multiple processes.\u003c/li\u003e\n\u003cli\u003eThe machine learning job detects a significant increase in the number of processes started within the RDP session.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers, alerting analysts to the anomalous activity.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly installed tools to move laterally to other systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful lateral movement attack can lead to significant damage, including data breaches, system compromise, and financial loss. While the severity is low, a spike in RDP processes can be an early indicator of compromise. Attackers often use RDP to propagate through a network after gaining initial access, making this detection critical for preventing widespread damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable host IP collection by following the configuration steps in the \u003ca href=\"https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields\"\u003eElastic Defend documentation\u003c/a\u003e to ensure the \u003ccode\u003ehost.ip\u003c/code\u003e field is populated.\u003c/li\u003e\n\u003cli\u003eInstall the Lateral Movement Detection integration assets as described in the rule\u0026rsquo;s setup instructions to enable the machine learning job \u003ccode\u003elmd_high_sum_rdp_number_of_processes_ea\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview and tune the anomaly threshold to reduce false positives based on your organization\u0026rsquo;s typical RDP usage.\u003c/li\u003e\n\u003cli\u003eInvestigate RDP sessions flagged by this rule to identify the source of the process spike and potential malicious activity as described in the rule\u0026rsquo;s \u0026ldquo;Triage and Analysis\u0026rdquo; notes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T14:35:00Z","date_published":"2024-01-23T14:35:00Z","id":"/briefs/2024-01-rdp-process-spike/","summary":"A machine learning job has detected an unusually high number of processes started within a single Remote Desktop Protocol (RDP) session, potentially indicating lateral movement activity.","title":"Spike in Number of Processes in an RDP Session","url":"https://feed.craftedsignal.io/briefs/2024-01-rdp-process-spike/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","threat-detection","attack.command-and-control"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert focuses on identifying security threats detected by Okta\u0026rsquo;s ThreatInsight. Okta ThreatInsight analyzes traffic patterns and user behavior to identify and block malicious login attempts, brute-force attacks, and other suspicious activities. When ThreatInsight identifies a security threat, it generates a system log event with the eventType \u003ccode\u003esecurity.threat.detected\u003c/code\u003e. This event serves as a high-level indicator of potential command and control activity within the Okta environment. Defenders should investigate these alerts promptly to determine the nature and scope of the threat and take appropriate remediation steps. This detection leverages Okta system logs and is relevant for organizations using Okta as their identity provider.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker attempts to gain unauthorized access to an Okta account, possibly through credential stuffing or brute-force attacks.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s ThreatInsight analyzes the login attempt, evaluating factors such as IP address reputation, geographical location, and login frequency.\u003c/li\u003e\n\u003cli\u003eThreatInsight identifies the login attempt as a security threat based on predefined risk factors.\u003c/li\u003e\n\u003cli\u003eOkta generates a system log event with eventType \u003ccode\u003esecurity.threat.detected\u003c/code\u003e, recording details of the suspicious activity.\u003c/li\u003e\n\u003cli\u003eThe security team receives an alert based on the Sigma rule detecting the \u003ccode\u003esecurity.threat.detected\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the alert, examining the associated IP address, user account, and other relevant log data.\u003c/li\u003e\n\u003cli\u003eBased on the investigation, the security team takes appropriate remediation steps, such as blocking the IP address, resetting the user\u0026rsquo;s password, or enabling multi-factor authentication.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack targeting Okta could lead to unauthorized access to sensitive data, account takeover, and disruption of services. The impact of such an attack depends on the level of access granted to the compromised account and the sensitivity of the data accessible through Okta. Successful exploitation can lead to lateral movement within an organization\u0026rsquo;s cloud infrastructure and potentially compromise other critical systems.\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\u003esecurity.threat.detected\u003c/code\u003e events in Okta system logs.\u003c/li\u003e\n\u003cli\u003eInvestigate all triggered alerts to determine the nature and scope of the threat.\u003c/li\u003e\n\u003cli\u003eReview Okta\u0026rsquo;s ThreatInsight configuration to ensure it is properly configured and tuned for your environment (references: Okta ThreatInsight documentation).\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious activity, such as unusual login patterns, account lockouts, and password resets (references: Okta system log documentation).\u003c/li\u003e\n\u003cli\u003eEnforce strong password policies and multi-factor authentication to reduce the risk of unauthorized access.\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-security-threat/","summary":"This alert detects when Okta's ThreatInsight identifies a security threat within an Okta environment, potentially indicating command and control activity.","title":"Okta Security Threat Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-security-threat/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["OneDrive","Chrome","Brave","Opera","Discord","Slack","Microsoft 365","SharePoint"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","windows","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Google","Brave Software","Opera","Discord","Slack"],"content_html":"\u003cp\u003eAdversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. This detection focuses on identifying connections from Windows hosts to a predefined list of commonly abused web services from processes running outside of typical program installation directories, indicating a potential C2 channel leveraging legitimate services. The rule aims to detect this behavior by monitoring network connections and DNS requests originating from unusual locations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is achieved via an unknown method (e.g., phishing, exploit).\u003c/li\u003e\n\u003cli\u003eMalware is installed on the victim\u0026rsquo;s system, likely outside typical program directories.\u003c/li\u003e\n\u003cli\u003eThe malware establishes a DNS connection to a commonly abused web service (e.g., pastebin.com, raw.githubusercontent.com) to obscure C2 traffic.\u003c/li\u003e\n\u003cli\u003eThe malware sends encrypted or encoded commands to the web service.\u003c/li\u003e\n\u003cli\u003eThe web service acts as an intermediary, relaying the commands to the attacker\u0026rsquo;s C2 server.\u003c/li\u003e\n\u003cli\u003eThe C2 server responds with instructions, which are then relayed back to the compromised host through the same web service.\u003c/li\u003e\n\u003cli\u003eThe malware executes the received commands, potentially leading to data exfiltration, lateral movement, or other malicious activities.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access and control over the compromised system using the web service as a hidden C2 channel.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to data theft, system compromise, and further propagation within the network. Since commonly used web services are utilized, the malicious activity can blend in with legitimate network traffic, making it difficult to detect. The impact can range from minor data breaches to complete network compromise, depending on the attacker\u0026rsquo;s objectives and the level of access gained.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Commonly Abused Web Services via DNS\u003c/code\u003e to your SIEM to identify suspicious DNS queries to known C2 web services originating from anomalous processes.\u003c/li\u003e\n\u003cli\u003eEnable DNS query logging on Windows endpoints to provide the data source required for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview network connection logs for processes outside standard installation directories communicating with domains listed in the \u003ccode\u003equery\u003c/code\u003e section of the Sigma rule to identify potential C2 activity.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential impact of compromised hosts.\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-04-c2-web-services/","summary":"This rule detects command and control activity using common web services by identifying Windows hosts making DNS requests to a list of commonly abused web services from processes outside of known program locations, potentially indicating adversaries attempting to blend malicious traffic with legitimate network activity.","title":"Detection of Command and Control Activity via Commonly Abused Web Services","url":"https://feed.craftedsignal.io/briefs/2024-01-04-c2-web-services/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["lateral-movement","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert originates from a machine learning job designed to detect anomalous RDP session start times. RDP is a common vector for lateral movement, and attackers may initiate sessions during off-peak hours to evade detection. The machine learning model flags sessions started outside of normal business hours or on unusual weekdays. While not inherently malicious, this activity warrants investigation as it can be an early indicator of a broader attack. The rule is part of the Lateral Movement Detection (LMD) integration from Elastic, requiring a minimum stack version of 9.4.0 and leverages Entity Analytics (EA) fields. Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events using Elastic\u0026rsquo;s Anomaly Detection feature.\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 compromised credentials or a software vulnerability (not described in source).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages RDP to attempt lateral movement to other systems within the network.\u003c/li\u003e\n\u003cli\u003eThe RDP session is initiated at an unusual time or day, deviating from typical user behavior.\u003c/li\u003e\n\u003cli\u003eThe machine learning job detects this anomaly based on the unusual RDP session start time.\u003c/li\u003e\n\u003cli\u003eAn alert is triggered, flagging the potentially suspicious activity.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to access sensitive data or resources on the target system.\u003c/li\u003e\n\u003cli\u003eThe attacker could install malware or establish persistence mechanisms (not described in source).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful lateral movement attack can allow an attacker to gain access to sensitive data, compromise critical systems, and ultimately disrupt business operations. While the detection of an unusual RDP session is an early warning sign, it is critical to investigate these alerts promptly to prevent further escalation. If the suspicious RDP session is part of a broader attack, the impact could range from data theft to ransomware deployment. The lack of immediate action could lead to significant financial and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable host IP collection within Elastic Defend if using versions 8.18 and above, following the configuration steps in the \u003ca href=\"https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields\"\u003ehelper guide\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eEnsure the Lateral Movement Detection integration assets are installed, as well as file and Windows RDP process events collected by the Elastic Defend integration, as mentioned in the \u003ca href=\"https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate all alerts generated by the \u0026ldquo;Unusual Time or Day for an RDP Session\u0026rdquo; rule, correlating the RDP session with other security events.\u003c/li\u003e\n\u003cli\u003eTune the anomaly threshold (currently 70) to reduce false positives while maintaining effective detection capabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:50:00Z","date_published":"2024-01-03T18:50:00Z","id":"/briefs/2024-01-unusual-rdp-session/","summary":"A machine learning job detected an RDP session initiated at an unusual time or day, potentially indicating lateral movement activity within a network.","title":"Unusual Time or Day for an RDP Session Detected by Machine Learning","url":"https://feed.craftedsignal.io/briefs/2024-01-unusual-rdp-session/"},{"_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":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","execution","command and control","threat detection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies suspicious activity within Kubernetes environments where attackers leverage \u003ccode\u003ekubectl exec\u003c/code\u003e or similar API calls to execute commands within pods. Specifically, it focuses on instances where these commands involve using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to retrieve content over HTTPS. Attackers may use this technique to download malicious scripts, tools, or exfiltrate sensitive data from compromised pods. This activity is flagged based on decoded request URIs from Kubernetes audit logs, reconstructed command strings, and filtering of benign traffic related to cluster health checks and OIDC/JWKS endpoints. The rule aims to detect anomalous behavior that deviates from typical pod execution patterns, helping defenders identify potential intrusions or misuse of pod execution privileges. The rule was created on 2026/04/23 and last updated on 2026/04/23 according to the source.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to the Kubernetes cluster, possibly through compromised credentials or a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target pod within the cluster to execute commands within.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e or a similar API call to initiate a shell session within the target pod.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a command using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to download a malicious script, tool, or exfiltrate data over HTTPS. The URL is often encoded in the requestURI.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server records the exec call and its parameters in the audit logs.\u003c/li\u003e\n\u003cli\u003eThe detection rule decodes the requestURI, extracts the command string, and identifies the use of \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e with an HTTPS URL.\u003c/li\u003e\n\u003cli\u003eThe rule filters out known benign URLs associated with cluster health checks or OIDC/JWKS endpoints.\u003c/li\u003e\n\u003cli\u003eIf the command is identified as malicious, an alert is triggered, indicating a potential compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the deployment of malicious tools within the Kubernetes environment, potentially enabling lateral movement, data theft, or denial-of-service attacks.  Compromised pods could expose sensitive data or be used as a launchpad for further attacks on the cluster or other systems. The scope of impact depends on the permissions granted to the compromised pod 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 \u0026ldquo;Kubernetes Pod Exec with Curl or Wget to HTTPS\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview Kubernetes RoleBindings for \u003ccode\u003epods/exec\u003c/code\u003e to ensure only required principals retain access on sensitive namespaces.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the decoded URI and reconstructed command in the alert details.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict egress traffic from pods, limiting the potential for data exfiltration via HTTPS.\u003c/li\u003e\n\u003cli\u003eRegularly audit Kubernetes audit logs for suspicious activity related to pod execution and API calls.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:27:00Z","date_published":"2024-01-03T14:27:00Z","id":"/briefs/2024-01-kubernetes-pod-exec/","summary":"This rule detects Kubernetes pod exec API calls using curl or wget to fetch HTTPS URLs, potentially indicating malicious activity such as staging tools or exfiltrating data.","title":"Kubernetes Pod Exec with Curl or Wget to HTTPS","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Monitoring Agent","Cohesity Windows Agent"],"_cs_severities":["low"],"_cs_tags":["discovery","windows","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Cohesity"],"content_html":"\u003cp\u003eThe \u003ccode\u003ewhoami\u003c/code\u003e utility is commonly used by attackers post-compromise to gather information about the current user and their privileges on a compromised system. This information helps attackers assess their level of access and plan further actions within the environment, such as privilege escalation or lateral movement. This activity is most concerning when executed by SYSTEM accounts or from unusual parent processes. This detection identifies unusual or suspicious executions of \u003ccode\u003ewhoami.exe\u003c/code\u003e, especially when associated with system privileges or specific parent processes known to be abused by attackers. The rule is designed to function across various Windows environments and considers potential false positives from legitimate administrative 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 the Windows system through an exploit or compromised credentials.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation (Optional): The attacker may attempt to elevate privileges to a higher level, potentially SYSTEM.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker executes \u003ccode\u003ewhoami.exe\u003c/code\u003e to determine the current user and their privileges.\u003c/li\u003e\n\u003cli\u003eInformation Gathering: The attacker analyzes the output of \u003ccode\u003ewhoami.exe\u003c/code\u003e to understand the context of the compromised system.\u003c/li\u003e\n\u003cli\u003eLateral Movement (Conditional): Based on the information gathered, the attacker may attempt to move laterally to other systems.\u003c/li\u003e\n\u003cli\u003eFurther Exploitation: The attacker leverages the gathered information to further exploit the compromised system or network.\u003c/li\u003e\n\u003cli\u003ePersistence (Optional): The attacker may establish persistence to maintain access to the compromised system.\u003c/li\u003e\n\u003cli\u003eObjective Completion: The attacker achieves their final objective, such as data exfiltration or system disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and reconnaissance can allow attackers to gain a deeper understanding of a compromised system. This may lead to further exploitation, lateral movement, and ultimately, the exfiltration of sensitive data or the disruption of critical services. While the \u003ccode\u003ewhoami\u003c/code\u003e command itself is not inherently malicious, its suspicious usage often indicates malicious activity within a compromised environment. The severity is low because the execution of whoami by itself is not enough to confirm malicious activity, and further investigation is needed.\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 \u003ccode\u003ewhoami.exe\u003c/code\u003e executions (reference: logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Whoami Process Activity\u0026rdquo; to your SIEM and tune for your environment (reference: rule).\u003c/li\u003e\n\u003cli\u003eInvestigate parent processes of \u003ccode\u003ewhoami.exe\u003c/code\u003e for any suspicious or unusual activity (reference: Attack Chain).\u003c/li\u003e\n\u003cli\u003eMonitor for other discovery commands executed around the same time as \u003ccode\u003ewhoami.exe\u003c/code\u003e (reference: Related rules).\u003c/li\u003e\n\u003cli\u003eReview and tune the false positives outlined in the rule to minimize noise (reference: false_positives).\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-whoami-discovery/","summary":"This rule detects suspicious use of whoami.exe to display user, group, and privileges information for the user who is currently logged on to the local system, potentially indicating post-compromise discovery activity.","title":"Suspicious Whoami Process Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-whoami-discovery/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["SIEM"],"_cs_severities":["high"],"_cs_tags":["threat-detection","higher-order-rule","elastic-siem"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies high-severity alerts within Elastic SIEM that are observed for the first time within a 5-day window. The rule focuses on low-volume, newly observed alerts linked to a specific detection rule. By highlighting these novel alerts, analysts can more effectively prioritize their triage and incident response efforts. This allows security teams to focus on potentially new or evolving threats, rather than being overwhelmed by repeated alerts from well-known attack patterns. The rule aims to reduce alert fatigue and improve the speed and accuracy of threat detection and response. The logic excludes threat_match, machine_learning, and new_terms rule types to minimize noisy alerts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA malicious activity occurs on an endpoint or within a network, triggering an Elastic SIEM detection rule with a high severity score (\u0026gt;=73).\u003c/li\u003e\n\u003cli\u003eThe Elastic SIEM generates a security alert based on the triggered detection rule. This alert includes details about the event, the affected host, user, and the rule that was triggered.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;Newly Observed High Severity Detection Alert\u0026rdquo; rule, running every 5 minutes, queries the \u003ccode\u003e.alerts-security.*\u003c/code\u003e indices.\u003c/li\u003e\n\u003cli\u003eThe rule filters for alerts that meet specific criteria such as high risk score, excluding certain rule types like \u0026ldquo;threat_match\u0026rdquo;, \u0026ldquo;machine_learning\u0026rdquo;, and \u0026ldquo;new_terms\u0026rdquo;, and excluding endpoint alerts.\u003c/li\u003e\n\u003cli\u003eThe rule aggregates alerts by \u003ccode\u003ekibana.alert.rule.name\u003c/code\u003e to identify distinct alerts and calculates the first and last time each alert was observed.\u003c/li\u003e\n\u003cli\u003eThe rule determines if the alert is newly observed, defined as the first time it was seen within the last 10 minutes of the rule execution time. This helps filter out alerts that have been occurring for a longer period.\u003c/li\u003e\n\u003cli\u003eThe rule further filters for alerts affecting a single agent (\u003ccode\u003eagent_id_distinct_count == 1\u003c/code\u003e) and low alert counts (\u003ccode\u003ealerts_count \u0026lt;= 10\u003c/code\u003e), indicating a potentially novel or isolated incident.\u003c/li\u003e\n\u003cli\u003eThe final output highlights the newly observed, low-frequency, high-severity alert, allowing security analysts to investigate and respond accordingly.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leading to a newly observed high severity alert could indicate a novel or evolving threat that has not been previously seen in the environment. This can lead to a delayed response, potentially allowing the attacker to further compromise systems, exfiltrate data, or cause damage. The impact depends on the specific activity that triggered the underlying high severity alert, but could range from initial access to data breach or ransomware deployment. Failure to prioritize investigation of these new alerts can result in significant financial loss, reputational damage, and operational disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eNewly Observed High Severity Detection Alert\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eUse the \u003ccode\u003eInvestigation Steps\u003c/code\u003e outlined in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field as a guide to triage newly observed alerts.\u003c/li\u003e\n\u003cli\u003eReview the specific rule investiguation guide for further actions, as referenced in the original Elastic rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003cli\u003eConfigure alerting to notify security analysts immediately upon detection of a \u003ccode\u003eNewly Observed High Severity Detection Alert\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-newly-observed-high-severity-detection-alert/","summary":"This rule detects newly observed, low-frequency, high-severity Elastic SIEM detection alerts affecting a single agent, helping prioritize triage and response by highlighting alerts tied to specific detection rules that have not been seen previously for the host.","title":"Newly Observed High Severity Detection Alert in Elastic SIEM","url":"https://feed.craftedsignal.io/briefs/2024-01-newly-observed-high-severity-detection-alert/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Security"],"_cs_severities":["high"],"_cs_tags":["threat-detection","higher-order-rule","attack"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule correlates multiple security alerts associated with the same ATT\u0026amp;CK tactic on a single host within a defined time window (60 minutes). The purpose of this rule is to identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. This allows analysts to prioritize triage towards hosts with a higher likelihood of compromise. The rule specifically excludes noisy tactics such as Discovery, Persistence, and Lateral Movement, focusing instead on tactics like Credential Access, Defense Evasion, Execution, and Command and Control. It requires at least three unique detection rules to trigger, ensuring that the activity is not a single, isolated event. The rule also excludes alerts generated by Machine Learning and Threat Match rules, as well as some noisy rules such as \u0026ldquo;Agent Spoofing - Mismatched Agent ID\u0026rdquo; and \u0026ldquo;Process Termination followed by Deletion\u0026rdquo;.\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 host through methods like exploiting a vulnerability or using stolen credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExecution:\u003c/strong\u003e The attacker executes malicious code on the compromised host, potentially using tools like PowerShell or cmd.exe.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker attempts to evade detection by disabling security controls or obfuscating their actions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The attacker attempts to steal credentials from the compromised host, such as passwords or Kerberos tickets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommand and Control:\u003c/strong\u003e The attacker establishes a command and control channel to communicate with the compromised host.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFurther Exploitation:\u003c/strong\u003e The attacker uses the compromised host to move laterally within the network, potentially targeting other systems or data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Impact:\u003c/strong\u003e The attacker exfiltrates sensitive data from the network or causes damage to systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to significant data breaches, financial losses, and reputational damage. By identifying hosts exhibiting multiple alerts related to the same ATT\u0026amp;CK tactic, organizations can proactively respond to potential intrusions before they escalate into more serious incidents. Failure to detect and respond to these types of attacks can result in widespread compromise and significant disruption to business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided in this brief to your SIEM to detect hosts exhibiting multiple alerts within the same ATT\u0026amp;CK tactic. Tune the rule to your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate hosts that trigger the Sigma rule to determine the root cause of the alerts and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eReview and update your existing detection rules to ensure they are effective at detecting the latest threats and tactics.\u003c/li\u003e\n\u003cli\u003eEnable logging for process creation, network connections, and file modifications to provide more visibility into host activity and improve detection capabilities.\u003c/li\u003e\n\u003cli\u003eImplement a vulnerability management program to identify and patch vulnerabilities on your systems to prevent attackers from gaining initial access.\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-multiple-alerts-same-tactic/","summary":"This rule correlates multiple security alerts associated with the same ATT\u0026CK tactic on a single host within a defined time window, helping to identify hosts exhibiting concentrated malicious behavior indicative of an active intrusion or post-compromise activity, focusing on Credential Access, Defense Evasion, Execution, and Command and Control tactics.","title":"Multiple Alerts in Same ATT\u0026CK Tactic by Host","url":"https://feed.craftedsignal.io/briefs/2024-01-multiple-alerts-same-tactic/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","threat-detection"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies suspicious activity within Kubernetes environments where a single client fingerprint (defined by user, source IP, and user agent) rapidly retrieves multiple distinct Secret objects via the Kubernetes API. The rule focuses on detecting potential credential access or in-cluster reconnaissance attempts. The activity may involve successful and failed GET requests, where failed requests may reveal information about RBAC boundaries or confirm the existence of targeted secrets. This activity can indicate that an attacker is attempting to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. The rule excludes common sources such as the kube-controller-manager and kube-scheduler.\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, potentially by exploiting a vulnerability or compromising a service account.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a series of GET requests to the Kubernetes API, targeting Secret objects.\u003c/li\u003e\n\u003cli\u003eThe API server authenticates and authorizes the requests based on the attacker\u0026rsquo;s permissions and RBAC configurations.\u003c/li\u003e\n\u003cli\u003eSuccessful GET requests return the contents of the Secret objects.\u003c/li\u003e\n\u003cli\u003eFailed GET requests may reveal RBAC restrictions, namespace details, or secret existence.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the retrieved Secrets or error messages to gather sensitive information like credentials or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the gathered information to further compromise the cluster or exfiltrate data.\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 stored within Kubernetes Secrets, such as service account tokens, registry credentials, TLS keys, and application configuration. This can result in privilege escalation, lateral movement, and data exfiltration. The rule aims to detect unauthorized access to these resources, preventing attackers from gaining access to critical infrastructure and data. If successful, the attackers could also potentially gain access to connected cloud resources via exposed credentials.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Rapid Secret GET Activity\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eKubernetes Rapid Secret GET Activity\u003c/code\u003e Sigma rule, focusing on the \u003ccode\u003eEsql.outcome\u003c/code\u003e field to determine the success or failure of the requests.\u003c/li\u003e\n\u003cli\u003eReview RBAC configurations for the identified user accounts and source IPs to identify overly permissive access controls using \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003esource.ip\u003c/code\u003e, and \u003ccode\u003eEsql.namespaces\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for unusual API activity, specifically targeting GET requests to Secret objects using \u003ccode\u003ekubernetes.audit.objectRef.resource == \u0026quot;secrets\u0026quot;\u003c/code\u003e as a filter.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of compromised accounts, using \u003ccode\u003esource.ip\u003c/code\u003e to track connections.\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-kubernetes-secret-retrieval-burst/","summary":"Detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint, potentially indicating credential access or in-cluster reconnaissance.","title":"Kubernetes Rapid Secret GET Activity Against Multiple Objects","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secret-retrieval-burst/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["execution","windows","scripting","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies a common attack vector where adversaries download and execute malicious scripts on Windows systems. The rule focuses on detecting scripts (e.g., .js, .vbs, .ps1, .msi) that originate from internet sources (identified by the presence of \u003ccode\u003efile.origin_url\u003c/code\u003e or \u003ccode\u003efile.origin_referrer_url\u003c/code\u003e ) and are subsequently executed using scripting utilities. The rule specifically looks for file creations by web browsers and archive utilities (chrome.exe, msedge.exe, winrar.exe, 7zFM.exe, etc.) followed by execution of script interpreters (wscript.exe, cscript.exe, powershell.exe, mshta.exe, msiexec.exe) with command-line arguments referencing the downloaded script. This activity is often indicative of malicious intent, as legitimate scripts are typically sourced from trusted internal repositories or local file systems, and not directly downloaded and executed. The rule aims to detect suspicious parent-child process relationships (e.g., browser spawning a script interpreter) and identify potential initial access or execution attempts. The rule requires Elastic Defend and a minimum Elastic Stack version of 9.2.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user browses to a malicious website or opens a compromised email containing a link.\u003c/li\u003e\n\u003cli\u003eThe user clicks the link, which initiates a download of a malicious script file (e.g., .js, .vbs, .ps1, .msi) via a web browser (chrome.exe, msedge.exe).\u003c/li\u003e\n\u003cli\u003eThe browser saves the downloaded script file to the user\u0026rsquo;s Downloads folder.\u003c/li\u003e\n\u003cli\u003eThe user, either intentionally or through social engineering, executes the downloaded script.\u003c/li\u003e\n\u003cli\u003eWindows executes the script using a scripting utility like wscript.exe, cscript.exe, powershell.exe, mshta.exe, or msiexec.exe.\u003c/li\u003e\n\u003cli\u003eThe scripting utility executes the malicious code within the script, potentially establishing persistence, downloading additional payloads, or performing reconnaissance.\u003c/li\u003e\n\u003cli\u003eThe script may attempt to elevate privileges or bypass security controls to gain further access to the system.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as deploying ransomware, stealing sensitive data, or establishing a remote access backdoor.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to a variety of negative outcomes, including malware infection, data theft, and system compromise. If the downloaded script is malicious, it can allow attackers to gain a foothold on the system, escalate privileges, and move laterally within the network. This can result in significant financial losses, reputational damage, and disruption of business operations. The number of victims and affected sectors can vary depending on the scale and scope of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Elastic Defend integration to collect necessary event data, as described in the \u003ca href=\"https://ela.st/install-elastic-defend\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Execution of a Downloaded Windows Script\u0026rdquo; to your SIEM and tune for your environment to detect the execution of downloaded scripts.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging and file creation events to provide the necessary data for the Sigma rules to function correctly.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to restrict the execution of unauthorized scripts and scripting utilities to reduce the risk of similar threats in the future, as mentioned in the \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eBlock known malicious domains and URLs identified in related threat intelligence feeds to prevent users from downloading malicious scripts in the first place.\u003c/li\u003e\n\u003cli\u003eEducate users about the dangers of downloading and executing untrusted scripts from the internet, as this is a common initial access vector.\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-downloaded-script-execution/","summary":"This rule identifies the creation and subsequent execution of a Windows script downloaded from the internet, a technique used by adversaries for initial access and execution on Windows systems.","title":"Execution of a Downloaded Windows Script","url":"https://feed.craftedsignal.io/briefs/2024-01-downloaded-script-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["lateral-movement","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies suspicious instances of the Remote Desktop Services ActiveX Client (mstscax.dll) being loaded from unusual or unauthorized locations on Windows systems. Attackers may leverage RDP lateral movement techniques by loading this DLL in unauthorized contexts to gain access and control over other systems within the network. The rule focuses on detecting anomalous loading patterns of mstscax.dll outside typical system paths, which can be indicative of malicious lateral movement attempts. This detection is applicable to environments using Elastic Defend and Sysmon.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises a system within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally using RDP.\u003c/li\u003e\n\u003cli\u003eTo facilitate the RDP connection, the attacker executes a process that loads the mstscax.dll.\u003c/li\u003e\n\u003cli\u003eThe mstscax.dll is loaded from a location outside the standard system paths (e.g., not from C:\\Windows\\System32).\u003c/li\u003e\n\u003cli\u003eThe system logs the image load event, capturing the process and the location from which mstscax.dll was loaded.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies the unusual loading of mstscax.dll based on the configured criteria.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes a remote desktop session to a target system.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control over the target system, enabling further malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can allow unauthorized access to sensitive systems and data, leading to potential data breaches, financial losses, and reputational damage. Lateral movement via RDP can allow attackers to expand their control within the network, compromising additional systems and escalating the impact of the attack. Early detection of suspicious mstscax.dll loading can prevent further propagation of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious RDP Client Image Load\u003c/code\u003e to your SIEM and tune the \u003ccode\u003eprocess.executable\u003c/code\u003e exclusions for your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 7 (Image Loaded) to capture the necessary data for the Sigma rule \u003ccode\u003eSuspicious RDP Client Image Load\u003c/code\u003e to function.\u003c/li\u003e\n\u003cli\u003eReview the process executable path in alerts to determine if \u003ccode\u003emstscax.dll\u003c/code\u003e was loaded from an unusual or unauthorized location.\u003c/li\u003e\n\u003cli\u003eInvestigate the network connections associated with the process to identify any suspicious remote connections or lateral movement attempts as described in the Overview.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the ability of adversaries to move laterally within the network as described in the Overview.\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-suspicious-rdp-client-imageload/","summary":"The rule detects suspicious loading of the Remote Desktop Services ActiveX Client (mstscax.dll) from unusual locations, potentially indicating RDP lateral movement on Windows systems.","title":"Suspicious RDP Client Image Load","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-rdp-client-imageload/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AeroAdmin","AnyDesk","Atera Agent","AweSun","APC Admin","APC Host","BeyondTrust","Remote Support","BarracudaRMM","Domotz Agent","DWService","FleetDeck Commander","GetScreen","GoTo","Impero Client","Impero Server","ISLLight","ISLLightClient","JumpCloud Agent","Level","LvAgent","LogMeIn","Lunixar","ManageEngine Remote Access Plus","MeshAgent","Mikogo","NinjaRMMAgent","NinjaRMMAgenPatcher","ninjarmm-cli","Parsec","Pulseway","Radmin","RealVNC","RemotePC","RemoteDesktopManager","RPCSuite","RustDesk","RemoteUtilities","Kaseya","ScreenConnect","Splashtop","Supremo","SyncroLive","TacticalRMM","Tailscale","TeamViewer","Tiflux","ToDesk","Twingate","TightVNC","UltraVNC","UltraViewer","AnyAssist","Velociraptor","ToolsIQ","ZohoAssist"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","rmm","windows","threat-detection"],"_cs_type":"advisory","_cs_vendors":["AeroAdmin","AnyDesk","Atera","AweSun","APC","BeyondTrust","BarracudaRMM","Domotz","DWService","FleetDeck","GetScreen","GoTo","Impero","ISLOnline","JumpCloud","Level","LogMeIn","Lunixar","ManageEngine","MeshCentral","Mikogo","NinjaOne","Parsec","Pulseway","Radmin","RealVNC","RemotePC","Devolutions","RPCSuite","RustDesk","RemoteUtilities","Kaseya","ScreenConnect","Splashtop","Supremo","TacticalRMM","Tailscale","TeamViewer","Tiflux","ToDesk","Twingate","TightVNC","UltraVNC","UltraViewer","AnyAssist","Velociraptor","ToolsIQ","ZohoAssist"],"content_html":"\u003cp\u003eThis detection rule identifies Windows hosts running multiple remote monitoring and management (RMM) tools from different vendors within an eight-minute timeframe. While legitimate MSP environments may utilize multiple tools, this activity can also indicate malicious behavior, such as an attacker establishing redundant access to a compromised system. The rule maps various RMM processes to vendor labels, ensuring that multiple binaries from the same vendor do not inflate the count. The processes monitored include popular RMM tools like TeamViewer, AnyDesk, ScreenConnect, and many others. This rule is designed to detect suspicious activity within the environment and alert security teams to potential compromises. The timeframe is set to eight minutes to reduce false positives.\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 a Windows host, possibly through phishing or exploitation of a vulnerability.\u003c/li\u003e\n\u003cli\u003eTool Deployment: The attacker deploys an initial RMM tool for remote access and control.\u003c/li\u003e\n\u003cli\u003eSecondary Tool Deployment: The attacker deploys a second RMM tool from a different vendor to ensure redundant access in case the first tool is detected or removed.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker escalates privileges to gain SYSTEM or Administrator rights, if necessary, to maintain persistent access and control.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker uses the RMM tools to move laterally within the network to access additional systems and data.\u003c/li\u003e\n\u003cli\u003eData Exfiltration/Malicious Activity: The attacker uses the established RMM connections to exfiltrate sensitive data or perform other malicious activities such as 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 unauthorized access to sensitive systems and data, potentially resulting in data breaches, financial loss, and reputational damage. This detection rule helps identify hosts that might be compromised by malicious actors utilizing multiple RMM tools for command and control. Identifying potentially compromised systems is key to preventing widespread damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM to detect multiple RMM tools running on the same host within an eight-minute window.\u003c/li\u003e\n\u003cli\u003eInvestigate systems triggering this alert by reviewing process execution logs and network connections to identify the source of the RMM tool installation.\u003c/li\u003e\n\u003cli\u003eEnforce a policy of a single approved RMM stack per asset class to minimize the risk of unauthorized RMM tool usage.\u003c/li\u003e\n\u003cli\u003eTune the provided Sigma rules with host or organizational unit exceptions for legitimate MSP/IT tooling environments.\u003c/li\u003e\n\u003cli\u003eReview asset inventory and change tickets for approved RMM software to identify unauthorized installations.\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-multiple-rmm-vendors/","summary":"This detection identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window, potentially indicating compromise, shadow IT, or attacker staging of redundant access.","title":"Multiple Remote Management Tool Vendors on Same Host","url":"https://feed.craftedsignal.io/briefs/2024-01-02-multiple-rmm-vendors/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["lateral-movement","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief addresses the detection of high variance in Remote Desktop Protocol (RDP) session durations using machine learning. The detection, implemented in Elastic Security\u0026rsquo;s Lateral Movement Detection integration, aims to identify anomalous RDP usage patterns that may indicate malicious activity. Adversaries might establish long RDP sessions to maintain persistence and move laterally within a network. The prebuilt Elastic ML job \u0026ldquo;lmd_high_var_rdp_session_duration_ea\u0026rdquo; analyzes RDP session data to identify unusual deviations in session lengths, which could signify unauthorized access or malicious exploitation of compromised systems. The rule is triggered when the anomaly score exceeds a threshold of 70. Defenders should investigate any alerts generated by this rule to determine if the RDP sessions are legitimate or indicative of malicious activity.\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 a system via phishing or exploiting a vulnerability (not detailed in the source).\u003c/li\u003e\n\u003cli\u003eRDP Enabled: The attacker enables RDP on the compromised host or utilizes existing RDP configurations.\u003c/li\u003e\n\u003cli\u003eCredential Theft: The attacker steals credentials from the initially compromised system (not detailed in the source).\u003c/li\u003e\n\u003cli\u003eLateral Movement: Using the stolen credentials, the attacker establishes an RDP session to another host within the network.\u003c/li\u003e\n\u003cli\u003eSession Persistence: The attacker maintains a long and variable RDP session to the target host, potentially evading detection mechanisms.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker attempts to escalate privileges on the target host to gain further control (not detailed in the source).\u003c/li\u003e\n\u003cli\u003eData Exfiltration/Malware Deployment: The attacker uses the established RDP session to exfiltrate sensitive data or deploy malware to other systems (not detailed in the source).\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 potential deployment of malware or ransomware. While the exact number of potential victims is unknown, organizations that heavily rely on RDP for remote access are particularly vulnerable. This can disrupt business operations, lead to data breaches, and cause significant financial losses. The low severity of this rule reflects its nature as an anomaly detection rather than a signature-based detection of confirmed malicious activity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure \u003ccode\u003ehost.ip\u003c/code\u003e field is populated for Elastic Defend events by following the \u003ca href=\"https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields\"\u003ehelper guide\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eInstall the Lateral Movement Detection integration assets as described in the setup section of the rule.\u003c/li\u003e\n\u003cli\u003eReview and tune the anomaly threshold in the \u0026ldquo;High Variance in RDP Session Duration\u0026rdquo; rule in Elastic to minimize false positives based on your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u0026ldquo;High Variance in RDP Session Duration\u0026rdquo; rule by following the triage steps outlined in the rule\u0026rsquo;s note section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T10:00:00Z","date_published":"2024-01-02T10:00:00Z","id":"/briefs/2024-01-high-rdp-variance/","summary":"A machine learning job has detected unusually high variance of RDP session duration, potentially indicating lateral movement and session persistence by threat actors.","title":"High Variance in RDP Session Duration Detected via Machine Learning","url":"https://feed.craftedsignal.io/briefs/2024-01-high-rdp-variance/"}],"language":"en","title":"CraftedSignal Threat Feed — Threat Detection","version":"https://jsonfeed.org/version/1.1"}