Elastic Endpoint Security — CraftedSignal Threat Feed

GenAI Tools Accessing Sensitive Files for Credential Access and Persistence

hello@craftedsignal.io — Fri, 01 May 2026 22:46:51 +0000

Attackers are increasingly leveraging GenAI agents to automate the discovery and exfiltration of sensitive information, including credentials, API keys, and tokens stored within files on compromised systems. The observed activity involves GenAI tools accessing critical files such as cloud credentials, SSH keys, browser password databases, and shell configuration files. Successful exploitation allows attackers to harvest credentials, gain unauthorized access to systems, and establish persistence mechanisms for continued access. The GenAI tools mentioned include ollama, textgen, lmstudio, claude, cursor, copilot, codex, jan, gpt4all, gemini-cli, genaiscript, grok, qwen, koboldcpp, llama-server, windsurf, zed, opencode, and goose. This activity highlights the emerging threat landscape of AI-assisted attacks and the need for robust detection and mitigation strategies.

Attack Chain

Initial compromise of a system through an unrelated vulnerability or social engineering.
Installation or execution of a GenAI tool (e.g., ollama, lmstudio) on the compromised system.
The GenAI tool is configured or instructed to scan the file system for sensitive files.
The GenAI tool accesses files containing credentials, such as .aws/credentials, browser password databases (Login Data, key3.db), or SSH keys (.ssh/id_*).
The GenAI tool exfiltrates the harvested credentials and API keys to a remote server controlled by the attacker.
The attacker uses the stolen credentials to gain unauthorized access to cloud resources, internal systems, or other sensitive accounts.
The GenAI tool attempts to modify shell configuration files (e.g., .bashrc, .zshrc) to establish persistence.
Upon system restart or user login, the modified shell configuration executes malicious commands, granting the attacker persistent access.

Impact

Successful exploitation of this threat can lead to significant data breaches, unauthorized access to critical systems, and persistent compromise of affected environments. Attackers can leverage stolen credentials to escalate privileges, move laterally within the network, and exfiltrate sensitive data. The number of victims and sectors targeted are currently unknown, but the potential impact is widespread given the increasing adoption of GenAI tools in various industries. Credential theft leads to financial loss, intellectual property theft, and reputational damage.

Recommendation

Deploy the Sigma rule “GenAI Process Accessing Sensitive Files” to your SIEM to detect GenAI tools accessing sensitive files on endpoints.
Enable file access monitoring on systems where GenAI tools are used to capture access events for analysis.
Review and restrict the use of GenAI tools within the environment, especially concerning access to sensitive file paths.
Monitor for modifications to shell configuration files (e.g., .bashrc, .zshrc, .profile) as an indicator of persistence attempts.
Implement regular credential rotation policies to minimize the impact of stolen credentials.

AMSI Enable Registry Key Modification for Defense Evasion

hello@craftedsignal.io — Sat, 27 Jan 2024 18:23:00 +0000

Attackers can disable the Antimalware Scan Interface (AMSI) to evade detection by modifying the AmsiEnable registry key. This technique is commonly employed to execute malicious scripts without triggering security warnings or blocks. The AMSI, a Windows feature, allows applications and services to request the scanning of potentially malicious content (e.g., PowerShell scripts, JScript) before execution. By setting the AmsiEnable value to 0, an attacker can disable AMSI for the current user, effectively bypassing real-time script scanning. This action is often a precursor to deploying further malicious payloads or establishing persistence on a compromised system. This behavior has been observed since at least 2019 and continues to be a relevant defense evasion technique.

Attack Chain

An attacker gains initial access to the target system, possibly through phishing or exploiting a vulnerability.
The attacker executes a script or binary that attempts to modify the AmsiEnable registry key.
The script or binary uses reg.exe, PowerShell, or another tool to set the AmsiEnable registry value to 0. The registry key location is typically HKEY_USERS\\Software\Microsoft\Windows Script\Settings\AmsiEnable.
After successfully disabling AMSI, the attacker proceeds to execute malicious scripts or code. These scripts may use powershell.exe, wscript.exe, or cscript.exe.
The malicious scripts download and execute additional payloads, such as malware or remote access tools (RATs).
The attacker performs lateral movement within the network using the compromised system as a pivot.
The attacker attempts to establish persistence, ensuring continued access to the system even after reboots.
The attacker exfiltrates sensitive data or deploys ransomware to achieve their objectives.

Impact

Successful modification of the AmsiEnable registry key allows attackers to execute malicious scripts without triggering AMSI alerts, leading to potential malware infections, data breaches, and system compromise. Disabling AMSI significantly reduces the effectiveness of endpoint security solutions, making the system more vulnerable to attack. The impact can range from individual workstation compromise to widespread network infections, depending on the attacker’s objectives and the organization’s security posture.

Recommendation

Deploy the Sigma rule Detect AmsiEnable Registry Modification via Registry Events to your SIEM to detect modifications to the AmsiEnable registry key.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
Monitor process creation events for processes modifying registry keys, especially reg.exe and PowerShell, using the rule Detect AmsiEnable Registry Modification via Process Creation.
Investigate any alerts generated by these rules promptly to determine if the activity is malicious or legitimate.
Implement application control policies to restrict the execution of unsigned or untrusted scripts and binaries.
Harden systems by restricting user permissions to modify critical registry keys.

PowerShell Script with Encryption/Decryption Capabilities

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This threat brief focuses on the detection of PowerShell scripts utilizing .NET cryptography APIs for file encryption or decryption. Attackers often leverage these capabilities to encrypt data for impact, potentially leading to data exfiltration or ransomware deployment, or to decrypt staged payloads, circumventing traditional security measures. Defenders should be aware of PowerShell scripts employing symmetric cryptography classes (AES/Rijndael, SymmetricAlgorithm), key derivation helpers (PasswordDeriveBytes, Rfc2898DeriveBytes), explicit cipher configurations (CipherMode, PaddingMode), and functions that generate encryptors/decryptors. Identifying such scripts is crucial for preventing both data compromise and the execution of malicious payloads. This detection specifically targets Windows systems where PowerShell is commonly used for both legitimate administration and malicious activities.

Attack Chain

Attacker gains initial access to the target system (e.g., via compromised credentials or a phishing attack).
Attacker uploads or stages a PowerShell script containing encryption/decryption capabilities.
The PowerShell script utilizes .NET cryptography APIs (e.g., AESManaged, RijndaelManaged, PasswordDeriveBytes, Rfc2898DeriveBytes).
The script configures the cipher using CipherMode and PaddingMode.
The script invokes .CreateEncryptor() or .CreateDecryptor() methods to initialize the cryptographic operation.
If encrypting, the script iterates through target files, encrypting their content and potentially renaming or deleting originals.
If decrypting, the script processes an encrypted payload, converting it to executable form or writing it to a new artifact.
The attacker executes the decrypted payload or exfiltrates the encrypted data, completing their objective.

Impact

Successful exploitation can lead to significant data loss, system downtime, and financial damage. Data encryption for impact can render systems unusable, while the decryption of staged payloads can introduce malware into the environment. The number of victims can vary widely depending on the scope of the attack, ranging from individual workstations to entire networks. Targeted sectors may include any organization reliant on Windows-based systems, with potential consequences including operational disruption, reputational damage, and regulatory fines.

Recommendation

Enable PowerShell Script Block Logging to capture the events required for detection, specifically event ID 4104, as detailed in the Elastic PowerShell logging setup guide.
Deploy the Sigma rule PowerShell Script with Encryption/Decryption Capabilities to your SIEM to detect suspicious PowerShell scripts utilizing .NET cryptography APIs.
Investigate alerts triggered by the Sigma rule, focusing on powershell.file.script_block_text to understand the cryptographic intent and data flow.
Tune the Sigma rule by adding exceptions for legitimate PowerShell scripts that use encryption, referencing the “False positive analysis” section in this brief.

Persistence via WMI Event Subscription

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Windows Management Instrumentation (WMI) provides a powerful framework for managing Windows systems, but adversaries can abuse its capabilities to establish persistence. By creating WMI event subscriptions, attackers can execute arbitrary code in response to defined system events. This technique involves creating event filters, providers, consumers, and bindings that automatically run malicious code. This can be achieved through tools like wmic.exe, which allows the creation of event consumers such as ActiveScriptEventConsumer or CommandLineEventConsumer. Successful exploitation of WMI for persistence allows attackers to maintain unauthorized access to a compromised system, even after reboots or other system changes. This activity has been observed across various environments, highlighting the need for robust detection mechanisms to identify and prevent WMI-based persistence.

Attack Chain

An attacker gains initial access to a Windows system through unspecified means.
The attacker uses wmic.exe to create a WMI event filter that defines a specific event to monitor.
A WMI event consumer, such as ActiveScriptEventConsumer or CommandLineEventConsumer, is created using wmic.exe specifying the malicious code or script to execute when the event occurs.
A WMI binding is established between the event filter and the event consumer using wmic.exe, linking the event to the action.
The malicious WMI event subscription is activated, monitoring for the defined event.
When the specified event occurs, the WMI service triggers the execution of the associated malicious code or script through the event consumer.
The attacker gains persistent access to the system, as the WMI event subscription will re-activate after reboots.
The attacker can then perform additional malicious activities, such as lateral movement or data exfiltration.

Impact

Successful exploitation of WMI for persistence can allow an attacker to maintain long-term, unauthorized access to a compromised system. This can result in data theft, system compromise, and further malicious activities. While the exact number of victims is not specified in the source, the broad applicability of this technique means that many Windows systems are potentially at risk. If the attack succeeds, the attacker gains a foothold on the system that is difficult to detect and remove, which can lead to significant operational disruption and financial loss.

Recommendation

Enable process creation logging and monitor for wmic.exe with command-line arguments related to creating event consumers, specifically ActiveScriptEventConsumer or CommandLineEventConsumer, to trigger the Sigma rule “Detect Suspicious WMIC Process”.
Deploy the provided Sigma rule to your SIEM to detect suspicious WMI event subscription creation.
Review the investigation steps outlined in the provided documentation to triage and analyze potential WMI persistence attempts.
Monitor Windows Security Event Logs and Sysmon for events related to WMI activity for broader coverage.

Detection of Kali Linux Installation or Usage via Windows Subsystem for Linux (WSL)

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This detection identifies attempts to install or utilize Kali Linux through the Windows Subsystem for Linux (WSL). Attackers may leverage WSL to deploy Kali Linux as a means of circumventing traditional security measures and carrying out malicious operations within a Windows operating system. This behavior enables them to potentially blend their activities with legitimate WSL usage, making detection more challenging. The detection focuses on identifying specific processes and command-line arguments associated with Kali Linux installations and executions within the WSL environment, aiming to expose malicious actors utilizing this technique for nefarious purposes. This activity started being tracked in early 2023. Defenders should be aware of this technique, as it can be used to bypass security controls and perform malicious activities discreetly.

Attack Chain

An attacker gains initial access to a Windows system through methods outside the scope of this specific detection (e.g., phishing, exploitation of a vulnerability).
The attacker enables WSL on the target Windows system using PowerShell or command-line tools.
The attacker downloads the Kali Linux distribution for WSL from the Microsoft Store or another source.
The attacker uses wsl.exe with arguments like -d, --distribution, -i, or --install along with “kali*” to install the Kali Linux distribution.
Alternatively, the attacker directly executes the kali.exe binary located within the Kali Linux package path (e.g., C:\\Users\\*\\AppData\\Local\\packages\\kalilinux*).
Once Kali Linux is installed, the attacker uses it to perform various malicious activities, such as penetration testing, vulnerability scanning, or exploiting other systems on the network.
The attacker may leverage tools and utilities within Kali Linux to escalate privileges, move laterally, or exfiltrate sensitive data.
The final objective is typically to compromise the target system or network, steal valuable information, or disrupt operations.

Impact

A successful attack using Kali Linux within WSL can lead to significant damage, including data breaches, system compromise, and disruption of services. The use of Kali Linux provides attackers with a wide range of tools and capabilities for reconnaissance, exploitation, and post-exploitation activities. Depending on the attacker’s objectives, this can result in financial losses, reputational damage, and legal liabilities. Organizations across various sectors are vulnerable, as this technique can be used against any Windows system with WSL enabled.

Recommendation

Deploy the Sigma rule “Detect Kali Linux Installation via WSL” to your SIEM to detect the use of wsl.exe with specific Kali Linux installation arguments (rule).
Deploy the Sigma rule “Detect Kali Linux Executable via WSL” to your SIEM to detect the direct execution of kali.exe from the common install directories (rule).
Monitor process creation events for the execution of wsl.exe and kali.exe within the Windows environment (logsource).
Review and restrict the usage of WSL within the organization to only authorized users and systems (overview).
Implement application control policies to prevent the execution of unauthorized binaries, including kali.exe (overview).