<?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>Script — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/script/</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>Wed, 03 Jan 2024 14:30:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/script/feed.xml" rel="self" type="application/rss+xml"/><item><title>Suspicious PowerShell Execution via Windows Script Host</title><link>https://feed.craftedsignal.io/briefs/2024-01-script-powershell-execution/</link><pubDate>Wed, 03 Jan 2024 14:30:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-script-powershell-execution/</guid><description>Detection of PowerShell processes launched by cscript.exe or wscript.exe, indicative of potential malicious initial access or execution attempts.</description><content:encoded><![CDATA[<p>This detection identifies PowerShell execution initiated by Windows Script Host processes (cscript.exe or wscript.exe). Attackers often use Windows Script Host (WSH) to execute malicious scripts as an initial access method. These scripts can act as droppers for second-stage payloads or download tools and utilities necessary for further compromise. The rule focuses on the parent-child process relationship between WSH and PowerShell, highlighting a common technique used to bypass security controls and execute arbitrary commands on a compromised system. This activity is relevant to defenders as it represents a potential entry point for various attacks, including malware deployment and data exfiltration. The detection logic is based on process execution events observed in Windows environments and is designed to work with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The user receives a phishing email with a malicious attachment (e.g., a .vbs or .js file).</li>
<li>The user opens the attachment, which is processed by either wscript.exe or cscript.exe.</li>
<li>The scripting engine executes the embedded malicious code.</li>
<li>The script downloads a PowerShell script from a remote server or contains an embedded, obfuscated PowerShell command.</li>
<li>The script uses wscript.exe or cscript.exe to launch powershell.exe to execute the downloaded or embedded PowerShell script.</li>
<li>PowerShell executes, performing malicious actions such as downloading additional payloads, modifying system settings, or establishing persistence.</li>
<li>PowerShell attempts to connect to external command-and-control servers to receive further instructions.</li>
<li>The attacker gains initial access to the system and can proceed with lateral movement, data exfiltration, or other malicious activities.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation can lead to initial access, allowing attackers to deploy malware, steal sensitive information, or perform other malicious activities. The impact can range from data breaches and financial losses to reputational damage. The severity depends on the attacker&rsquo;s objectives and the level of access they gain. The number of affected systems depends on the scope of the phishing campaign or other initial access methods used to deliver the malicious script.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable Sysmon process creation logging to capture the necessary event data for the rules below.</li>
<li>Deploy the Sigma rules in this brief to your SIEM and tune for your environment.</li>
<li>Investigate process execution chains where cscript.exe or wscript.exe spawn powershell.exe using the provided Sigma rules.</li>
<li>Implement email security measures to block phishing emails with script attachments.</li>
<li>Monitor network connections originating from PowerShell processes for suspicious outbound traffic.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>initial-access</category><category>execution</category><category>windows</category><category>powershell</category><category>script</category></item><item><title>Suspicious Script Execution from Temporary Directory</title><link>https://feed.craftedsignal.io/briefs/2024-01-script-exec-temp/</link><pubDate>Tue, 02 Jan 2024 14:30:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-script-exec-temp/</guid><description>This brief covers a detection for suspicious script execution, such as PowerShell, WScript, or MSHTA, originating from common temporary directories, potentially indicating malware activity.</description><content:encoded><![CDATA[<p>This detection identifies suspicious script executions originating from temporary directories. Threat actors often leverage temporary folders to stage and execute malicious scripts, such as PowerShell, VBScript, or even HTML applications (MSHTA) to evade detection or bypass security controls. These scripts can be delivered through various means, including phishing attacks, drive-by downloads, or as part of a multi-stage malware infection. The execution of scripts from temporary directories is generally uncommon for legitimate software, making it a valuable indicator of potentially malicious activity. This detection focuses on identifying processes like powershell.exe, pwsh.exe, mshta.exe, wscript.exe, and cscript.exe executing from or referencing standard temporary paths in their command line.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>A malicious script (e.g., PowerShell, VBScript) is downloaded or dropped into a temporary directory such as <code>C:\Windows\Temp</code>, <code>\AppData\Local\Temp</code>, or similar.</li>
<li>The attacker uses a process like <code>cmd.exe</code> or <code>powershell.exe</code> to invoke the downloaded script.</li>
<li>The script executes, potentially performing reconnaissance, privilege escalation, or lateral movement.</li>
<li>The script may download additional payloads from a remote server.</li>
<li>The script establishes persistence through registry modification or scheduled tasks.</li>
<li>The script performs malicious actions such as data exfiltration or ransomware deployment.</li>
<li>The attacker attempts to remove the initial script files to cover their tracks.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation can lead to a range of consequences, including data theft, system compromise, and ransomware infection. The execution of malicious scripts from temporary directories can provide attackers with a foothold in the network, allowing them to move laterally, escalate privileges, and ultimately achieve their objectives. Depending on the script&rsquo;s capabilities, it could also lead to system instability or denial of service.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &ldquo;Suspicious Script Execution From Temp Folder&rdquo; to your SIEM to detect script execution from temporary directories. Tune the rule&rsquo;s filters for known-good software installers in your environment to reduce false positives.</li>
<li>Enable process creation logging with command line arguments to capture the necessary information for the Sigma rule (logsource: process_creation).</li>
<li>Investigate any alerts generated by the Sigma rule, focusing on the parent process and the script&rsquo;s actions.</li>
<li>Implement application control policies to restrict the execution of scripts from temporary directories where possible.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">threat</category><category>execution</category><category>script</category><category>temp</category></item></channel></rss>