<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Elastic Security — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/elastic-security/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Mon, 04 May 2026 14:17:05 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/elastic-security/feed.xml" rel="self" type="application/rss+xml"/><item><title>Potential Account Takeover - Logon from New Source IP</title><link>https://feed.craftedsignal.io/briefs/2024-01-account-takeover-new-source-ip/</link><pubDate>Mon, 04 May 2026 14:17:05 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-account-takeover-new-source-ip/</guid><description>The rule identifies a user account that normally logs in with high volume from one source IP suddenly logging in from a different source IP, potentially indicating account takeover or use of stolen credentials from a new location.</description><content:encoded><![CDATA[<p>This detection rule identifies potential account takeover activity by analyzing Windows Security Event Logs for unusual login patterns. Specifically, it looks for user accounts that typically log in with high frequency from a single source IP address but then exhibit successful logins from a different source IP address with significantly lower frequency. This pattern may indicate that an attacker has compromised the account credentials and is accessing the network from a new, potentially malicious, location. This activity is detected by analyzing Windows Security Event ID 4624 events related to successful logins. The rule is designed to trigger when a user account logs in from a new IP address after establishing a pattern of high-volume logins from a primary IP address.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access:</strong> The attacker gains access to valid user credentials through methods such as phishing, credential stuffing, or malware. (T1078)</li>
<li><strong>Successful Logon:</strong> The attacker uses the compromised credentials to successfully log in to a Windows system from a new IP address (Event ID 4624, Logon Type Network/RemoteInteractive).</li>
<li><strong>Lateral Movement (Possible):</strong> Once authenticated, the attacker may attempt to move laterally within the network to access additional resources or systems.</li>
<li><strong>Privilege Escalation (Possible):</strong> The attacker may attempt to escalate their privileges to gain administrative access to the system or domain (TA0004).</li>
<li><strong>Data Exfiltration (Possible):</strong> The attacker may attempt to exfiltrate sensitive data from the compromised system or network.</li>
<li><strong>Persistence (Possible):</strong> The attacker may attempt to establish persistence mechanisms to maintain access to the system or network over time.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful account takeover can have significant consequences, including unauthorized access to sensitive data, lateral movement within the network, privilege escalation, and data exfiltration. The rule specifically looks for logon patterns indicative of account takeover. If an account is taken over, attackers could potentially gain access to systems and data the user has rights to access.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule provided below to your SIEM and tune for your environment, paying close attention to the <code>max_logon</code> threshold.</li>
<li>Enable Audit Logon within Windows to ensure the events needed for detection are available as mentioned in the setup instructions.</li>
<li>Investigate any alerts generated by the Sigma rule by confirming with the account owner if they logged in from the new source IP.</li>
<li>Check the new source IP for reputation, geography, and whether it is expected as described in the rule&rsquo;s triage steps.</li>
<li>Correlate any generated alerts with other alerts for the same user or source IP such as logon failures, password changes, or MFA changes as part of your investigation.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>account-takeover</category><category>credential-access</category><category>windows</category></item><item><title>Multiple Alerts Involving a User Detection</title><link>https://feed.craftedsignal.io/briefs/2024-01-24-multiple-alerts-user/</link><pubDate>Wed, 24 Jan 2024 10:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-24-multiple-alerts-user/</guid><description>This rule identifies when multiple different alerts involving the same user are triggered, which could indicate a compromised user account and requires further investigation.</description><content:encoded><![CDATA[<p>This detection rule, sourced from Elastic&rsquo;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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to a user account, potentially through phishing, credential stuffing, or other methods.</li>
<li>The attacker attempts to escalate privileges within the compromised account.</li>
<li>The attacker performs reconnaissance activities, such as discovering sensitive files or network shares.</li>
<li>The attacker attempts to move laterally to other systems within the network using the compromised credentials.</li>
<li>The attacker accesses sensitive data, potentially exfiltrating it from the network.</li>
<li>These actions trigger various security alerts related to privilege escalation, lateral movement, and data access.</li>
<li>The &ldquo;Multiple Alerts Involving a User&rdquo; rule detects the correlation between these alerts based on the user ID.</li>
<li>Security analysts are alerted to investigate the compromised user account and contain the potential damage.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule <code>Multiple Alerts Involving a User</code> to your SIEM to detect potential user account compromises based on correlated alerts.</li>
<li>Enable audit logging on systems to capture user activity and generate alerts for suspicious actions.</li>
<li>Review and tune the threshold values (e.g., distinct alert count) in the Sigma rule to align with your environment and risk tolerance.</li>
<li>Use the <code>Resources: Investigation Guide</code> tag to access guidance on investigating triggered alerts and identifying compromised user accounts.</li>
<li>Implement role-based access control (RBAC) to minimize the impact of compromised accounts by limiting access to sensitive resources.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>threat-detection</category><category>higher-order-rule</category></item><item><title>PowerShell Kerberos Ticket Request via KerberosRequestorSecurityToken</title><link>https://feed.craftedsignal.io/briefs/2024-01-09-kerberos-ticket-request/</link><pubDate>Tue, 09 Jan 2024 18:45:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-09-kerberos-ticket-request/</guid><description>This rule detects PowerShell scripts that request Kerberos service tickets using KerberosRequestorSecurityToken, potentially indicating Kerberoasting attacks for offline password cracking of service accounts.</description><content:encoded><![CDATA[<p>This detection identifies PowerShell scripts leveraging the <code>KerberosRequestorSecurityToken</code> class to request Kerberos service tickets. Attackers often use this technique to perform Kerberoasting, where they obtain service tickets for various service principal names (SPNs) and crack the associated service account passwords offline. This activity can be indicative of an attacker attempting to gain unauthorized access to sensitive resources within the network. The rule is designed to trigger on potentially malicious uses of <code>KerberosRequestorSecurityToken</code> while attempting to filter out legitimate uses, such as those within Sentinel breakpoints or authorized Kerberos diagnostic scripts. Defenders should investigate any instances of this activity to determine whether it represents a genuine threat.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access:</strong> An attacker gains initial access to a Windows system, potentially through phishing, compromised credentials, or exploiting a vulnerability.</li>
<li><strong>Execution:</strong> The attacker executes a PowerShell script, either interactively or via a scheduled task or other means of remote execution.</li>
<li><strong>Obfuscation (Optional):</strong> The PowerShell script may be obfuscated to evade detection, using techniques such as Base64 encoding or string manipulation.</li>
<li><strong>Ticket Request:</strong> The script uses the <code>KerberosRequestorSecurityToken</code> class to request Kerberos service tickets for one or more SPNs.</li>
<li><strong>Data Collection:</strong> The script collects the requested service tickets and potentially saves them to a file or transmits them over the network.</li>
<li><strong>Credential Access:</strong> The attacker extracts the Kerberos hashes from the collected tickets.</li>
<li><strong>Offline Cracking:</strong> The attacker uses tools like John the Ripper or Hashcat to crack the service account passwords offline.</li>
<li><strong>Privilege Escalation/Lateral Movement:</strong> Upon successfully cracking the passwords, the attacker uses the compromised credentials to escalate privileges or move laterally within the network.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful Kerberoasting attacks can lead to the compromise of service accounts, potentially granting attackers unauthorized access to critical systems and sensitive data. The impact can range from data breaches and financial losses to complete system compromise and disruption of business operations. The rule&rsquo;s medium severity reflects the potential for significant impact if the attack succeeds.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable PowerShell Script Block Logging to capture the PowerShell script content necessary for detection, and ensure the logs are being ingested into your SIEM. Reference: <a href="https://ela.st/powershell-logging-setup">Setup instructions</a>.</li>
<li>Deploy the Sigma rule &ldquo;PowerShell Kerberos Ticket Request&rdquo; to your SIEM to detect suspicious use of <code>KerberosRequestorSecurityToken</code> in PowerShell scripts.</li>
<li>Investigate any alerts triggered by the Sigma rule, focusing on reconstructing the full script content, identifying the targeted SPNs, and analyzing the process execution context to determine if the activity is malicious.</li>
<li>Review Windows Security event logs on domain controllers for event ID 4769, filtering for the <code>TargetUserName</code> associated with the alerting user to identify related Kerberos ticket requests.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>kerberoasting</category><category>credential_access</category><category>windows</category></item><item><title>Multiple Alerts in Same ATT&amp;CK Tactic by Host</title><link>https://feed.craftedsignal.io/briefs/2024-01-multiple-alerts-same-tactic/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-multiple-alerts-same-tactic/</guid><description>This rule correlates multiple security alerts associated with the same ATT&amp;CK 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.</description><content:encoded><![CDATA[<p>This detection rule correlates multiple security alerts associated with the same ATT&amp;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 &ldquo;Agent Spoofing - Mismatched Agent ID&rdquo; and &ldquo;Process Termination followed by Deletion&rdquo;.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access:</strong> An attacker gains initial access to a host through methods like exploiting a vulnerability or using stolen credentials.</li>
<li><strong>Execution:</strong> The attacker executes malicious code on the compromised host, potentially using tools like PowerShell or cmd.exe.</li>
<li><strong>Defense Evasion:</strong> The attacker attempts to evade detection by disabling security controls or obfuscating their actions.</li>
<li><strong>Credential Access:</strong> The attacker attempts to steal credentials from the compromised host, such as passwords or Kerberos tickets.</li>
<li><strong>Command and Control:</strong> The attacker establishes a command and control channel to communicate with the compromised host.</li>
<li><strong>Further Exploitation:</strong> The attacker uses the compromised host to move laterally within the network, potentially targeting other systems or data.</li>
<li><strong>Data Exfiltration or Impact:</strong> The attacker exfiltrates sensitive data from the network or causes damage to systems.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful attack can lead to significant data breaches, financial losses, and reputational damage. By identifying hosts exhibiting multiple alerts related to the same ATT&amp;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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule provided in this brief to your SIEM to detect hosts exhibiting multiple alerts within the same ATT&amp;CK tactic. Tune the rule to your environment to reduce false positives.</li>
<li>Investigate hosts that trigger the Sigma rule to determine the root cause of the alerts and take appropriate remediation steps.</li>
<li>Review and update your existing detection rules to ensure they are effective at detecting the latest threats and tactics.</li>
<li>Enable logging for process creation, network connections, and file modifications to provide more visibility into host activity and improve detection capabilities.</li>
<li>Implement a vulnerability management program to identify and patch vulnerabilities on your systems to prevent attackers from gaining initial access.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>threat-detection</category><category>higher-order-rule</category><category>attack</category></item></channel></rss>