Security logging and monitoring disabled

Threat snapshot

Before an attacker executes their primary objective, they frequently take steps to disable the logging and monitoring controls that would expose them. Disabling security event logging, suppressing PowerShell script block output, blocking command-line argument capture, and bypassing the Antimalware Scan Interface are not attacks in themselves. They are preparation steps that make every subsequent attack harder to detect and easier to deny. An attacker who successfully disables these controls before running their payload does not just evade detection for that payload. They create a gap in the audit trail that persists until the controls are restored, affecting every security event generated during that window.

Log360 covers this threat with four detection rules, each targeting a distinct registry-based mechanism used to disable a specific security monitoring capability. Together they give the SOC an early warning when an attacker is preparing the environment for undetected operation. Because these are preparation steps rather than attack steps, detecting them provides an opportunity to intervene before the primary attack takes place.

At a glance

How this attack works

Each of the four detection rules targets a different registry-based mechanism for disabling a security monitoring capability. Understanding what each one does and why it matters is important for accurate triage and response.

PowerShell Script Execution Monitoring Disabled

PowerShell Script Block Logging captures the decoded content of every PowerShell script block that executes, even when the script is obfuscated, encoded, or downloaded in memory. It is one of the most valuable sources of post-exploitation visibility available on Windows. Attackers disable it by writing to the registry:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

EnableScriptBlockLogging   REG_DWORD   0

Setting EnableScriptBlockLogging to 0 silences Event ID 4104 output, preventing PowerShell commands from being recorded regardless of what they do. An attacker who disables Script Block Logging before running a credential harvesting or lateral movement script eliminates the most detailed record of what that script contained.

Disable Security Events Logging Adding Reg Key MiniNt

The MiniNt registry key, when present, instructs the Windows Event Log service to suppress security event generation. Writing this key effectively silences the Windows Security event log on the affected host:

HKLM\SYSTEM\CurrentControlSet\Control\MiniNt

The MiniNt key's presence alone is the trigger. It does not require a specific value to be set. When this key exists, Windows reduces or halts Security event log output depending on the OS version and configuration. The result is a host that continues to operate normally but generates no Security event log entries, creating a complete blind spot in the SIEM for that endpoint during the period the key is present.

Prevent Command Line Logging via Registry

Windows Process Creation auditing generates Event ID 4688 for every new process. When command-line logging is enabled, the ProcessCommandLine field in that event contains the full arguments passed to the process, which is the telemetry source for detecting tools like net.exe share deletion, ntdsutil.exe IFM creation, and many other attack techniques. Attackers can suppress this field by modifying the registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit

ProcessCreationIncludeCmdLine_Enabled   REG_DWORD   0

Setting this value to 0 disables command-line capture in process creation events. Process creation events continue to fire, but the ProcessCommandLine field is empty. Every rule that depends on command-line argument content, including the net.exe share deletion rule, the ntdsutil IFM rule, and the CHCP obfuscation rule, is effectively blinded on that host for the duration of the change.

AmsiEnable Registry Key Tampered

The Antimalware Scan Interface (AMSI) allows security products to scan PowerShell scripts, VBScript, JScript, and other script content at runtime before execution. It is the primary mechanism by which antivirus and EDR products intercept and block malicious scripts even when they are obfuscated or downloaded in memory. Attackers disable AMSI by writing to a per-user registry key:

HKCU\SOFTWARE\Microsoft\Windows Script\Settings

AmsiEnable   REG_DWORD   0

Setting AmsiEnable to 0 under the current user's hive disables AMSI scanning for that user's script execution sessions. Unlike the other three techniques, AMSI tampering does not require administrator rights because the key is in HKCU rather than HKLM. This means any standard user account that has been compromised can disable AMSI for their own session without any privilege escalation.

Attack chain

The table below maps each stage of a security logging and monitoring disablement attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A retail organisation with a centralised Windows environment and a Log360 deployment receives an alert that an employee's account has been used to authenticate from two different countries within 30 minutes. The security team flags the account for review but does not immediately disable it. That 30-minute window is all the attacker needs.

Using the compromised account, which has local administrator rights on several shared workstations, the attacker connects via RDP to a finance team workstation. In a PowerShell session, they execute four registry modifications in sequence: setting EnableScriptBlockLogging to 0, creating the MiniNt key, setting ProcessCreationIncludeCmdLine_Enabled to 0, and setting AmsiEnable to 0 in HKCU. The entire sequence takes under 20 seconds.

With monitoring controls disabled, the attacker runs a PowerShell-based credential harvesting script that extracts saved browser passwords and Windows credential manager entries. They then run a modified version of Mimikatz delivered as a heavily obfuscated PowerShell script. Because AMSI is disabled, the script is not intercepted by the endpoint protection product. Because Script Block Logging is disabled, no Event ID 4104 record of the script content is generated. Because command-line logging is disabled, the PowerShell invocation in the process creation log shows no arguments. The Security event log on the workstation has also been partially suppressed by the MiniNt key.

Log360 does fire four alerts, one for each of the registry modifications. But because the alerts are routed to a general queue rather than a priority escalation path, they sit unreviewed for two hours. By the time the SOC reviews them, the attacker has already used the harvested credentials to access the payroll system.

Why this happens
Registry modification alerts are often treated as lower priority than process execution or network alerts because registry changes appear technical and abstract. Defenders who are not familiar with what Script Block Logging, MiniNt, and AMSI disablement mean operationally may not recognise that four registry modification alerts firing in the same 20-second window represent the most urgent possible signal: an attacker who is actively preparing the environment for undetected attack. The preparation step is the last detection opportunity before the primary payload executes.

Business impact: What can go wrong

Disabling security logging and monitoring controls has consequences that extend well beyond the immediate attack:

• Audit trail destruction: disabling event logging and command-line capture creates permanent gaps in the audit record. Even after the controls are restored, the activity that occurred during the disabled window cannot be reconstructed from log data alone. The scope of the breach during that window may never be fully determinable.
• Detection blind spots enabling downstream attacks: every attack technique that fires on process command-line arguments, PowerShell script content, or Security event data is blinded on the affected host for the duration of the control disablement. The attacker can operate freely using techniques that would otherwise trigger immediate alerts.
• AMSI bypass enabling malware delivery: with AMSI disabled, obfuscated and in-memory malware scripts are not scanned by endpoint security products before execution. This defeats one of the primary last-resort defenses against fileless malware and PowerShell-based payloads.
• Compliance and regulatory exposure: failure to maintain continuous security event logging is a direct violation of PCI DSS Requirement 10.5, HIPAA 164.312(b), and ISO 27001 A.12.4. A gap in the audit log caused by deliberate disablement of monitoring controls, even if the disablement was the result of an attack rather than negligence, constitutes a control failure that may require disclosure.
• Incident response degradation: when security logging controls are disabled before an attack, the incident response team faces the investigation with an incomplete evidence base. The time required to scope and remediate the incident increases significantly, as does the likelihood that some attacker activity goes undetected.
• Recurrence risk: if the monitoring disablement is not detected and remediated promptly, the attacker can return to the host and execute further attacks under the same disabled monitoring conditions without any additional preparation.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the security logging and monitoring disablement rules can fire reliably, ensure the following are in place:

• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 13 (Registry Value Set) and Event ID 12 (Registry Key Created) for the specific registry paths covered by each rule. All four detection rules depend on Sysmon registry monitoring. Without Sysmon coverage of these key paths, the rules will not fire.
• Windows Object Access auditing for the registry is enabled, generating Event ID 4657 as a supplementary audit record. This provides an independent kernel-level record of the registry modifications that is separate from the Sysmon driver, making it harder for an attacker to suppress both sources simultaneously.
• Windows Process Creation auditing with command-line logging is enabled before the attack occurs. This is a prerequisite specifically for the command-line logging disablement rule: the rule detects the action of disabling command-line logging, but detecting that action itself depends on process creation events that may include the command used to make the change.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360 in near-real-time. Monitoring disablement actions are time-critical: the shorter the forwarding latency, the smaller the window during which the attacker can operate under disabled controls before the SOC is alerted.

Note
There is an inherent detection timing challenge in this use case. An attacker who disables Script Block Logging and command-line logging before executing their payload reduces the telemetry quality of events generated after the disablement. The four detection rules in this use case fire on the disablement actions themselves, not on the subsequent activity. This means that even if the attacker successfully reduces post-disablement telemetry, the disablement events are still captured by Sysmon registry monitoring, which operates independently of the logging controls being disabled. Acting on these alerts quickly is therefore critical.

Detecting security logging and monitoring disablement using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable all four rules: PowerShell Script Execution Monitoring Disabled, Disable Security Events Logging Adding Reg Key MiniNt, Prevent Command Line Logging via Registry, and AmsiEnable Registry Key Tampered. Configure an alert profile for the same.

Step 2: Read the alert

The alert will display the hostname, the account that made the registry modification, the specific registry path and value written, the process responsible for the write, and the timestamp. Review the process name first: Group Policy service processes writing to Script Block Logging or command-line logging settings are the primary false positive scenario. Any other process, particularly PowerShell, reg.exe, or an unrecognised binary, writing to these keys is high confidence. Then check the account: a standard user account modifying HKLM-based logging keys is impossible without privilege escalation and is immediately suspicious. A standard user modifying AmsiEnable in HKCU is possible without escalation and warrants investigation based on context.

Investigating an alert

When any of the four security logging disablement rules fires, an L2 analyst should work through the following steps:

• Check immediately whether multiple rules fired. Query Log360 for all four rule names on the same host in the preceding five minutes. If two or more have fired in the same window, this is a confirmed attack preparation sequence. Escalate to L3 immediately without waiting to complete the remaining investigation steps.
• Identify the process responsible for the registry write. Open the Incident Workbench and find the process that made the modification. Determine whether it was a Group Policy update process, a named administrative tool, PowerShell, reg.exe, or an unrecognised binary. Trace the process back to its parent to identify whether it was run interactively, via a remote session, or launched by another process.
• Assess the current monitoring state of the affected host. Determine which monitoring controls are currently disabled. If Script Block Logging, command-line logging, or the MiniNt key are currently active on the host, the quality of subsequent telemetry from that host is degraded. Flag this in the incident record and apply additional monitoring scrutiny to any events generated by that host during the disabled window.
• Check for preceding suspicious activity. Query Log360 for the 30 minutes before the first disablement alert on the same host. Look for unusual logon events, new process creation events, or network connections from unrecognised sources that may indicate how the attacker gained access before beginning the disablement sequence.
• Check for follow-on activity. Query Log360 for the period after the disablement alert on the same host. Even with reduced telemetry quality, process creation events, network connections, and file system activity may still be visible. Look for PowerShell executions, credential access tools, lateral movement commands, or outbound connections to unrecognised external IPs.
• Verify whether the change was authorised. Check the change management system for any approved configuration change, Group Policy update, or software installation that would explain the registry modification. If the change is not attributable to a documented administrative action, treat it as confirmed malicious and restore the affected monitoring controls immediately as part of containment.

Escalation trigger
Escalate immediately to L3 if two or more of the four rules fired on the same host within a 60-second window; if the registry modification was made by a process other than the Group Policy service or a documented configuration management tool; if the modification was made via a remote session from an unrecognised source IP; or if any follow-on PowerShell execution, credential access activity, or outbound network connection to an external IP occurred on the same host after the disablement action. These combinations confirm an active attack in preparation.

Responding and remediating

Immediate containment

• Restore all disabled monitoring controls immediately. Set EnableScriptBlockLogging to 1, delete the MiniNt key if present, set ProcessCreationIncludeCmdLine_Enabled to 1, and set AmsiEnable to 1 in the affected user's HKCU hive. Restoring these controls re-enables telemetry and allows Log360 and endpoint security tools to resume full monitoring of the host.
• Isolate the affected host from the network if follow-on attack activity has been confirmed or if the disablement sequence was part of an active intrusion. Use EDR host isolation to prevent lateral movement while the investigation proceeds.
• Disable the account that made the registry modifications if it was a named user account and the activity was not authorised. Force a password reset and review all systems the account has authenticated to in the preceding 72 hours.

Forensic preservation

• Export the Sysmon operational log and Windows Security event log from the affected host covering the full period from the first disablement alert. Pay particular attention to the window during which monitoring controls were disabled. Even with reduced telemetry, partial records of activity during that window are valuable and should be preserved before any remediation.
• Document the exact time window during which each monitoring control was disabled. This information is required for the incident record, for compliance reporting, and for assessing which other detection rules may have been blinded during the attack window. Any alert that would have fired during the disabled period should be flagged as potentially missed.
• If PowerShell was used to make the registry modifications, check whether PowerShell transcript logging was enabled on the host (separate from Script Block Logging). Transcript logs, if present, capture the full PowerShell session output even when Script Block Logging is disabled and may provide visibility into what the attacker did after disabling monitoring.

Eradication and recovery

• Enforce the correct monitoring control values via Group Policy rather than local registry settings. Group Policy-enforced values override local registry changes and will be restored automatically at the next Group Policy refresh cycle even if an attacker modifies them again. This is the most resilient remediation for three of the four controls: Script Block Logging, command-line logging, and AMSI settings can all be managed via Group Policy.
• Scan all other endpoints for the same registry modifications. Query Log360 for the same four registry paths across all agents to identify whether the disablement was applied to additional hosts as part of a broader campaign.
• Review all attack-related activity that may have occurred on the affected host during the monitoring disabled window. Use any available alternative telemetry sources such as network flow logs, proxy logs, DNS logs, and EDR process tree data to reconstruct what happened during the gap. Document the limitations of the reconstruction for the incident report.

False positive guidance

The four detection rules target controls that are rarely modified in normal enterprise operations. False positives are uncommon but occur in the following scenarios:

• Group Policy updates: the most common source of false positives for the Script Block Logging and command-line logging rules is a Group Policy refresh that sets these values. If Group Policy is configured to manage these settings, the registry write will occur at every Group Policy refresh cycle on every endpoint in scope. Identify the Group Policy update process as the writing process and verify the value being written is the correct, security-enabling value (1 for both). If Group Policy is writing a value of 0, that is a misconfigured Group Policy that should be corrected, not excluded.
• Security product installation: some endpoint protection products and vulnerability scanners temporarily modify AMSI settings during installation or scanning operations. Verify the writing process is a signed vendor binary and that the AmsiEnable value is restored to 1 after the operation completes. A permanent change to AmsiEnable set to 0 is not a legitimate security product behaviour.
• Developer and testing environments: developers testing PowerShell scripts or security researchers running authorised assessments may disable Script Block Logging or AMSI temporarily in a test environment. Verify the host is a documented development or test machine, the account is a known developer account, and the change is consistent with a documented testing activity. Even in testing environments, monitoring disablement should be documented and time-limited.
• Configuration management tools: automated configuration management systems such as Ansible, Puppet, or Chef may write registry values as part of their configuration baseline enforcement. If a configuration management tool is responsible for the write, the parent process will be the agent binary and the timing will align with a scheduled configuration run. Verify the value being written is correct and create a scoped exclusion for the configuration management agent process.

Key differentiator

Legitimate registry modifications to monitoring controls are made by the Group Policy service or a documented configuration management agent, result in security-enabling values (not disabling values), are applied consistently across multiple hosts on a schedule, and can be attributed to a specific policy or configuration baseline. An illegitimate modification will be made by PowerShell, reg.exe, or an unrecognised process, will set values that disable monitoring rather than enable it, will often appear on a single host rather than across many, and will occur outside any documented policy deployment or configuration management schedule.

Hardening and prevention

The following controls reduce the risk of monitoring controls being disabled by an attacker:

• Enforce Script Block Logging and command-line logging via Group Policy rather than local registry settings. Group Policy values applied from a domain controller take precedence over local registry changes and are restored automatically at each Group Policy refresh. An attacker who modifies the local registry value will have the change overwritten within the next refresh cycle (typically 90 minutes by default, configurable to be shorter).
• Apply registry ACLs to restrict write access to the Script Block Logging, MiniNt, and command-line logging registry paths. Limit write access to SYSTEM and the Group Policy service account only, removing write access from interactive administrator sessions. This prevents an attacker with local admin rights from modifying these keys interactively.
• Monitor Group Policy for changes to PowerShell and audit policy settings. Any change to the Group Policy Objects that control Script Block Logging or command-line logging is as significant as a local registry change, because a compromised domain account with Group Policy write access could disable monitoring across the entire domain simultaneously.
• Deploy Sysmon with tamper protection enabled. Sysmon can be installed with protection against process termination and service disablement. An attacker who cannot kill the Sysmon service cannot suppress its registry monitoring events even if they successfully modify the logging control registry values.
• Configure Windows Event Log to write to a protected, centralised store. Events forwarded to Log360 via WEF or the Log360 agent cannot be deleted from the SIEM even if an attacker clears the local Windows Event Log on the endpoint. Near-real-time forwarding minimises the window during which a local log clear can destroy evidence before it is captured.
• Enable Protected Event Logging for PowerShell, which encrypts Script Block Log entries using a certificate so that they can only be read by authorised parties. This prevents an attacker from reading Script Block Logs to determine what has already been captured, and ensures the integrity of captured events.