https://feed.craftedsignal.io/vendors/n-able/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 09 Jan 2024 10:00:00 +0000https://feed.craftedsignal.io/briefs/2024-01-09-disable-powershell-scriptblock-logging/Tue, 09 Jan 2024 10:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-09-disable-powershell-scriptblock-logging/Attackers may disable PowerShell Script Block Logging by modifying the registry to conceal their activities on the host and evade detection by setting the `EnableScriptBlockLogging` registry value to 0, impacting security monitoring and incident response capabilities.Attackers frequently disable PowerShell Script Block Logging to evade detection and hide malicious activities on compromised systems. By modifying the EnableScriptBlockLogging registry value to ‘0’ or ‘0x00000000’, adversaries can significantly reduce the visibility into their PowerShell-based attacks. This technique is particularly effective when followed by script-driven activity, making it harder for security teams to identify and respond to threats. This behavior has been observed across multiple environments, including those utilizing endpoint detection and response solutions such as Elastic Defend, Microsoft Defender XDR, SentinelOne, and CrowdStrike. The rule was last updated on 2026-05-04 and is designed to detect these specific registry modifications.

Attack Chain

1. Initial Access: An attacker gains initial access to a Windows system, possibly through phishing or exploitation of a vulnerability.
2. Privilege Escalation: The attacker may attempt to escalate privileges to gain necessary permissions to modify the registry.
3. Defense Evasion: The attacker modifies the registry to disable PowerShell Script Block Logging by setting HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging to 0 or 0x00000000 using reg.exe or PowerShell itself.
4. Execution: The attacker executes malicious PowerShell scripts, leveraging the disabled logging to avoid detection. These scripts may be used for reconnaissance, lateral movement, or data exfiltration.
5. Persistence: The attacker establishes persistence using various techniques, such as creating scheduled tasks or modifying registry keys to ensure continued access to the system.
6. Command and Control: The attacker establishes a command and control channel to communicate with the compromised system and issue further instructions.
7. Lateral Movement: The attacker moves laterally to other systems on the network, compromising additional assets.
8. Impact: The attacker achieves their final objective, such as data theft, ransomware deployment, or disruption of services.

Impact

Successful disabling of PowerShell Script Block Logging can severely hinder incident response efforts, allowing attackers to operate undetected for extended periods. Organizations may experience data breaches, financial losses, and reputational damage. The impact can be widespread as attackers leverage compromised systems for lateral movement and further exploitation. The loss of PowerShell logging can blind security teams, making it difficult to reconstruct attacker actions and contain the breach.

Recommendation

• Deploy the Sigma rule PowerShell_Script_Block_Logging_Disabled to your SIEM to detect registry modifications that disable PowerShell Script Block Logging.
• Monitor registry events for changes to the EnableScriptBlockLogging value, focusing on events with registry.data.strings set to “0” or “0x00000000” (see rule PowerShell_Script_Block_Logging_Disabled).
• Enable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively (see references).
• Review and harden PowerShell execution policies to prevent unauthorized script execution (related to tactic TA0005).
• Implement strict access controls to limit who can modify registry settings related to PowerShell logging (related to tactic TA0005).

]]>mediumadvisorydefense-evasionpowershellregistryhttps://feed.craftedsignal.io/briefs/2024-01-rmm-dns-non-browser/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-rmm-dns-non-browser/Detection of DNS queries to remote monitoring and management (RMM) domains from non-browser processes indicating potential misuse of legitimate remote access tools for command and control.This detection identifies DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains originating from processes that are not web browsers. This activity can indicate the use of legitimate RMM tools for malicious purposes, such as command and control, persistence, or lateral movement within a network. The detection aims to surface RMM clients, scripts, or other non-browser activities contacting these services without legitimate user interaction. Defenders should investigate processes making these queries to confirm expected behavior and validate the security posture of their managed assets. The rule is based on a list of known RMM domains and excludes common browser processes to reduce false positives.

Attack Chain

1. An attacker gains initial access to a Windows host through unspecified means.
2. The attacker deploys or leverages an existing RMM tool on the compromised host.
3. The RMM tool, running as a non-browser process, initiates a DNS query to resolve a command and control server associated with the RMM service (e.g., teamviewer.com).
4. The DNS query is made by a process other than a known web browser (chrome.exe, firefox.exe, etc.).
5. The compromised host establishes a connection to the resolved IP address associated with the RMM domain.
6. The attacker uses the RMM tool to execute commands, transfer files, or perform other malicious activities on the compromised host.
7. The attacker may use the RMM tool for lateral movement, pivoting to other systems within the network.
8. The attacker achieves their objective, which could include data exfiltration, ransomware deployment, or maintaining persistent access.

Impact

Compromise via abused RMM software can lead to full system compromise, data theft, or deployment of ransomware. While the number of affected victims is unknown, the sectors most likely to be impacted include any organization that relies on RMM tools for IT management. Successful exploitation allows attackers to bypass traditional security controls by using legitimate software, making detection more challenging.

Recommendation

• Deploy the Sigma rule “DNS Queries to Known RMM Domains from Non-Browser Processes” to your SIEM and tune the RMM domain list for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the DNS query and its parent process.
• Implement application control policies to restrict the execution of unauthorized RMM tools.
• Enable Sysmon DNS event logging to ensure the necessary data is available for the detection rule.
• Correlate with other alerts to identify potential compromises.
• Review process.code_signature for trusted RMM publishers and investigate any unsigned or unexpected signers.

]]>mediumadvisorycommand-and-controlremote-accesswindows