« Deprecated - Encoded Executable Stored in the Registry Proxy Execution via Console Window Host »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

IIS HTTP Logging Disabled

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

IIS HTTP Logging Disabled

edit

Identifies when Internet Information Services (IIS) HTTP Logging is disabled on a server. An attacker with IIS server access via a webshell or other mechanism can disable HTTP Logging as an effective anti-forensics measure.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Elastic Endgame
  • Resources: Investigation Guide
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 318

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating IIS HTTP Logging Disabled

Possible investigation steps

  • What IIS HTTP logging scope did AppCmd disable?
  • Focus: process.command_line: "dontLog" value, site/application target, "system.webServer/httpLogging", and apphost commit.
  • Implication: escalate when production-site or server-wide successful-request logging is disabled, because webshell traffic may leave no IIS log trail; lower suspicion when scope and timing fit a narrow non-production logging test, migration, or recovery action.
  • Is this the expected IIS AppCmd utility?
  • Focus: process.executable, process.pe.original_file_name, process.code_signature.subject_name, process.code_signature.trusted.
  • Implication: escalate when AppCmd is renamed, unsigned, or outside the IIS administration path; lower suspicion when trusted Microsoft AppCmd runs from that path. Identity alone never clears disablement.
  • Does the operator and session context fit IIS administration on this host?
  • Focus: user.id, user.name, user.domain, process.Ext.session_info.logon_type.
  • Hint: if session enrichment is absent, keep session unresolved and rely on operator plus parent-lineage evidence; absence is not benign.
  • Implication: escalate when a rare operator, service-account misuse, unexpected remote-interactive/network session, or newly elevated token made the change; lower suspicion when the operator/session pattern is recognized for this IIS host.
  • What launched AppCmd?
  • Focus: process.parent.executable, process.parent.command_line, process.parent.entity_id.
  • Implication: escalate when the launcher includes web workers, shells, script hosts, archive tools, or web-content chains; lower suspicion when lineage stays inside one recognized IIS management/deployment workflow.
  • Do surrounding process commands show cleanup or adjacent IIS anti-forensics?
  • Focus: process starts from the same AppCmd parent on the same host.id, reading process.command_line. !{investigate{"description":"","label":"Process starts from the same AppCmd parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: prefer process.entity_id or process.parent.entity_id; if unavailable, use host.id + process.pid + a tight alert window and treat the join as weaker.
  • Implication: escalate for log deletion, "applicationHost.config"/"web.config" rewrites, PowerShell IIS configuration changes, or no re-enable command after a temporary-change explanation; lower suspicion when commands only re-enable logging or stay inside the same recognized IIS workflow.
  • If local evidence remains suspicious or unresolved, do related alerts change scope or urgency?
  • Focus: related alerts for the same user.id, emphasizing webshell, archive, persistence, anti-forensics, or suspicious IIS tooling. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: the host-scoped alert view for the same host.id separates one operator’s history from server activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broaden response when either scope shows precursor webshell access, staging, persistence, or repeated anti-forensics; keep the case local only when related alerts stay limited to the same recognized maintenance window.
  • Escalate on unauthorized logging disablement, suspicious lineage, missing re-enable evidence, or adjacent IIS compromise; close only when scope, identity, operator/session, lineage, surrounding activity, and related alerts match one recognized workflow and external confirmation verifies exact activity telemetry cannot prove; preserve evidence and escalate when evidence is mixed or incomplete.

False positive analysis

  • IIS migration, recovery, short troubleshooting, or controlled logging tests can trigger this rule. Confirm trusted Microsoft AppCmd from the IIS administration path, intended site/application scope in process.command_line, recognized user.id, matching parent workflow, and re-enable process evidence for temporary changes. Use change records or owner confirmation only after process evidence matches; conflicting process evidence blocks benign closure. If records are unavailable, require the same AppCmd path, signer, parent workflow, targeted IIS scope, operator, session type, and host.id to recur across prior alerts. A different target, operator, lineage, or missing re-enable command keeps the alert unresolved.
  • Before creating an exception, validate the same AppCmd identity (process.executable plus process.code_signature.subject_name), parent executable, command scope, user.id, and host.id across prior alerts. Avoid exceptions on AppCmd alone, "/dontLog" alone, or the host alone.

Response and remediation

  • If suspicious but unconfirmed, preserve the alert record, process.entity_id, process.command_line, targeted IIS scope, parent lineage, operator/session fields, related-alert context, remaining IIS logs, and current IIS configuration before containment. Apply reversible containment first, and weigh host criticality before isolating internet-facing or revenue-bearing IIS servers.
  • If confirmed benign, reverse temporary containment and document the AppCmd path, targeted IIS scope, operator, session type, parent lineage, re-enable evidence, and external confirmation that justified closure. Create an exception only after the same pattern recurs.
  • If confirmed malicious, contain the host or administrative session when command scope, lineage, operator context, or related alerts show unauthorized anti-forensics. Record the same evidence set before terminating processes, killing sessions, deleting artifacts, or changing IIS configuration.
  • Re-enable IIS HTTP logging at the affected site or server scope, export remaining IIS logs before rotation, restore deleted logs from backups or snapshots when possible, and compare "applicationHost.config" or "web.config" changes tied to the same activity.
  • Eradicate only the webshells, scripts, archives, persistence artifacts, and configuration changes uncovered during the investigation. Rotate credentials when the operator/session evidence suggests account compromise, then remediate the initial access or administrative-control failure that allowed logging to be disabled.
  • After containment, scope other hosts for the same AppCmd arguments, IIS configuration-edit commands, log-cleanup commands, and adjacent IIS anti-forensics variants. Retain the process and case-export evidence that supported the final disposition.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and
  process.args : "/dontLog*:*True" and
  not process.parent.name : "iissetup.exe"

Framework: MITRE ATT&CKTM

« Deprecated - Encoded Executable Stored in the Registry Proxy Execution via Console Window Host »