<?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 License V2 — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/elastic-license-v2/</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 21:42:34 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/elastic-license-v2/feed.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Pod Exec Sensitive File or Credential Path Access</title><link>https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/</link><pubDate>Mon, 04 May 2026 21:42:34 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/</guid><description>This rule detects Kubernetes pod exec sessions where the decoded command line references sensitive files or paths such as mounted service account tokens, kubelet and control-plane configuration, host identity stores, private keys, and process environment dumps, aiming to identify potential lateral movement, privilege escalation, or credential theft.</description><content:encoded><![CDATA[<p>This detection identifies Kubernetes pod exec sessions accessing sensitive files or credential paths. The goal is to detect attackers attempting to steal credentials or configuration information from within Kubernetes pods. This often occurs after initial access and may precede lateral movement, privilege escalation, or data exfiltration. The detection focuses on command lines that reference paths related to service account tokens, kubelet configuration, host identity stores, common private keys, keystore extensions, process environment dumps, and configuration files with embedded secrets. The rule is designed to catch both interactive and scripted access, and includes exclusions for benign reads of resolv.conf.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.</li>
<li>Attacker uses <code>kubectl exec</code> or similar tools to execute commands within a pod.</li>
<li>The executed command attempts to read sensitive files or directories within the pod&rsquo;s filesystem, such as <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code> to obtain the pod&rsquo;s service account token.</li>
<li>The command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like <code>/etc/shadow</code> or <code>/etc/passwd</code> for credential access.</li>
<li>The attacker may attempt to dump process environments via <code>/proc/&lt;pid&gt;/environ</code> to extract sensitive information stored as environment variables.</li>
<li>The attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.</li>
<li>The attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.</li>
<li>The final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful attack can lead to the compromise of sensitive data, including credentials, configuration files, and application secrets. This can enable attackers to move laterally within the Kubernetes cluster, escalate privileges, and potentially gain control over the entire environment. The severity of the impact depends on the sensitivity of the data exposed and the level of access achieved by the attacker.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.</li>
<li>Investigate any alerts triggered by the Sigma rule, focusing on the <code>Esql.access_type</code> field to prioritize incidents.</li>
<li>Review and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.</li>
<li>Implement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.</li>
<li>Monitor Kubernetes audit logs for suspicious <code>kubectl exec</code> activity, including unusual command lines or access patterns.</li>
<li>Regularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.</li>
<li>Use the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>kubernetes</category><category>credential-access</category><category>execution</category></item><item><title>PowerShell Obfuscation via Concatenated Dynamic Command Invocation</title><link>https://feed.craftedsignal.io/briefs/2024-01-posh-concat-obfuscation/</link><pubDate>Wed, 03 Jan 2024 15:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-posh-concat-obfuscation/</guid><description>This rule detects PowerShell scripts that build commands from concatenated string literals within dynamic invocation constructs, a technique used by attackers to obscure execution intent, bypass keyword-based detections, and evade AMSI.</description><content:encoded><![CDATA[<p>This detection rule identifies PowerShell scripts employing concatenated string literals within dynamic invocation constructs like <code>&amp;()</code> or <code>.()</code>. This obfuscation technique allows attackers to construct commands dynamically, making it harder to detect their malicious intent based on static analysis or keyword matching. By breaking commands into smaller, concatenated strings, attackers aim to bypass traditional signature-based detections and evade AMSI (Anti-Malware Scan Interface). This technique has been observed in various campaigns where threat actors attempt to execute malicious code while minimizing the chances of detection. This activity is particularly concerning for defenders, as it highlights a common method to bypass security measures.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).</li>
<li>The attacker executes a PowerShell script on the compromised system.</li>
<li>The PowerShell script uses string concatenation to build malicious commands dynamically.</li>
<li>Dynamic invocation constructs like <code>&amp;()</code> or <code>.()</code> are used to execute the concatenated commands.</li>
<li>The obfuscated commands bypass keyword-based detections and AMSI.</li>
<li>The attacker performs malicious activities, such as downloading additional payloads.</li>
<li>The attacker executes the downloaded payloads to establish persistence or exfiltrate data.</li>
<li>The attacker achieves their final objective, such as stealing sensitive information or deploying ransomware.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation can lead to complete system compromise, data theft, and potential ransomware deployment. Attackers can leverage this technique to evade security controls and execute malicious commands undetected. The impact is high because it allows attackers to bypass common defenses and maintain persistence on the system, affecting potentially hundreds or thousands of systems across an organization.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable PowerShell Script Block Logging to capture the events necessary for this detection, as indicated in the setup instructions linked in the source material.</li>
<li>Deploy the Sigma rule <code>Detect PowerShell Obfuscation via String Concatenation</code> to your SIEM and tune for your environment to detect the use of concatenated strings in PowerShell commands.</li>
<li>Investigate alerts generated by the Sigma rule, focusing on the reconstructed PowerShell commands and the processes that launched them, as outlined in the triage and analysis section of the source material.</li>
<li>Monitor for follow-on activities, such as child processes, file modifications, and network connections originating from PowerShell processes exhibiting obfuscation techniques.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>defense-evasion</category><category>powershell</category><category>obfuscation</category></item><item><title>Detecting RPC Traffic to the Internet</title><link>https://feed.craftedsignal.io/briefs/2024-01-rpc-internet-access/</link><pubDate>Wed, 03 Jan 2024 14:27:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-rpc-internet-access/</guid><description>This brief focuses on detecting Remote Procedure Call (RPC) traffic originating from internal networks and reaching the public internet, which is indicative of potential initial access or backdoor activity.</description><content:encoded><![CDATA[<p>The Remote Procedure Call (RPC) protocol, while essential for legitimate system administration tasks such as remote maintenance and resource sharing within internal networks, poses a significant security risk when exposed to the internet. Threat actors frequently target and exploit RPC services as an initial access vector or to establish backdoors within compromised systems. This exposure allows attackers to remotely execute commands, move laterally within the network, and potentially exfiltrate sensitive data. This brief provides detection strategies to identify such anomalous RPC traffic, enabling security teams to proactively mitigate potential threats. The detection focuses on identifying TCP traffic to port 135 from internal IP ranges to external IP addresses.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker compromises a host within the internal network, potentially through phishing or exploiting a vulnerability.</li>
<li>The compromised host initiates an RPC connection to an external IP address on TCP port 135.</li>
<li>The attacker uses the RPC connection to enumerate network resources and identify potential targets for lateral movement.</li>
<li>Using the RPC connection, the attacker attempts to authenticate to other systems within the network.</li>
<li>Upon successful authentication, the attacker remotely executes commands on the target system via RPC.</li>
<li>The attacker installs malware or a backdoor on the target system for persistence.</li>
<li>The attacker leverages the established foothold to further propagate within the network, compromising additional systems.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of RPC services exposed to the internet can lead to a complete compromise of the internal network. Attackers can gain initial access, move laterally, exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations. A single exposed RPC service can serve as a gateway for widespread damage.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Implement the provided Sigma rule to detect RPC traffic from internal IP ranges to external destinations on TCP port 135, focusing on network traffic logs.</li>
<li>Investigate any alerts generated by the Sigma rule, prioritizing systems exhibiting suspicious RPC activity (Sigma rule, logsource: network_connection).</li>
<li>Ensure that RPC services are not directly exposed to the internet. Implement firewall rules to restrict access to authorized internal IP ranges only.</li>
<li>Continuously monitor network traffic for anomalous RPC activity and correlate with other security events (logsource: network_connection).</li>
<li>Review and update firewall configurations to block unauthorized outbound connections on port 135 (logsource: firewall).</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>network-traffic</category><category>initial-access</category><category>lateral-movement</category><category>rpc</category></item><item><title>Potential Machine Account Relay Attack via SMB</title><link>https://feed.craftedsignal.io/briefs/2024-01-machine-account-relay/</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-machine-account-relay/</guid><description>The rule identifies potential relay attacks against a machine account by detecting network share access events originating from a remote source IP but utilizing the target server's computer account, which may indicate an SMB relay attack.</description><content:encoded><![CDATA[<p>This detection rule identifies potential SMB relay attacks targeting machine accounts in Windows environments. The attack involves an adversary intercepting and relaying authentication requests to gain unauthorized access to network resources. The detection focuses on analyzing Windows Security Event Logs for file share access events (event code 5145) where the source IP address is different from the target server&rsquo;s IP address, but the user name matches the target server&rsquo;s computer account (ends with &ldquo;$&rdquo;). This activity could indicate that an attacker is relaying SMB authentication requests from a compromised system to the target server, effectively impersonating the machine account. Detecting this behavior is crucial for identifying and mitigating potential lateral movement and credential access attempts within the network.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker compromises a host within the network.</li>
<li>The attacker initiates an SMB connection to a target server.</li>
<li>The attacker intercepts the authentication request.</li>
<li>The attacker relays the authentication request to another server using the target server&rsquo;s machine account.</li>
<li>The target server authenticates the relayed request, granting access to the attacker.</li>
<li>The attacker gains unauthorized access to network shares and resources on the target server.</li>
<li>The attacker attempts lateral movement to other systems within the domain.</li>
<li>The attacker performs credential access activities, such as dumping credentials or accessing sensitive data.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows attackers to gain unauthorized access to network resources, potentially leading to lateral movement, data theft, or system compromise. A successful SMB relay attack can compromise critical systems and expose sensitive data, potentially impacting hundreds or thousands of systems within the domain. This can result in significant financial losses, reputational damage, and legal liabilities.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable Audit Detailed File Share monitoring to generate the necessary event logs for detection (Setup instructions: <a href="https://ela.st/audit-detailed-file-share)">https://ela.st/audit-detailed-file-share)</a>.</li>
<li>Deploy the provided Sigma rule &ldquo;Potential Machine Account Relay Attack via SMB&rdquo; to your SIEM to detect suspicious SMB activity based on event code 5145 and abnormal source IP addresses.</li>
<li>Investigate alerts generated by the Sigma rule by reviewing surrounding authentication events (event codes 4624 and 4625) to confirm the use of machine accounts from unexpected source IPs.</li>
<li>Implement network segmentation and restrict SMB access between systems to limit the potential impact of SMB relay attacks.</li>
<li>Enforce SMB signing or Extended Protection to prevent man-in-the-middle attacks.</li>
<li>Monitor for related alerts as described in the transform.investigate sections, focusing on suspicious authentication, service creation, persistence, or credential access on the host.id.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>credential-access</category><category>smb-relay</category><category>windows</category></item></channel></rss>