T1499.004 Google Chronicle · YARA-L

Detect Application or System Exploitation in Google Chronicle

Adversaries may exploit software vulnerabilities to crash applications or systems, denying availability to users. Unlike resource exhaustion or flooding techniques, exploitation-based DoS leverages logic flaws or memory corruption bugs (buffer overflows, use-after-free, integer overflows, protocol violations) to trigger unhandled exceptions, assertion failures, or kernel panics. Critical services including DNS servers (BIND9 CVE-2015-5477), web servers, databases, and ICS/SCADA devices (Siemens SIPROTEC CVE-2015-5374 exploited by Industroyer/CRASHOVERRIDE) are common targets. Auto-restart mechanisms may restore crashed services, enabling adversaries to repeatedly re-exploit for persistent denial of service. Crash-induced conditions may cascade into data destruction, firmware corruption, or full service stop outcomes.

MITRE ATT&CK

Tactic
Impact
Technique
T1499 Endpoint Denial of Service
Sub-technique
T1499.004 Application or System Exploitation
Canonical reference
https://attack.mitre.org/techniques/T1499/004/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1499_004_exploitation_dos_crash_loop {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects exploitation-based DoS via repeated application crashes with exploit exception codes on critical services (MITRE T1499.004)"
    severity = "HIGH"
    priority = "HIGH"
    mitre_attack_tactic = "Impact"
    mitre_attack_technique = "T1499.004"
    reference = "https://attack.mitre.org/techniques/T1499/004/"
    created = "2024-01-01"
    version = "1.0"

  events:
    $crash.metadata.event_type = "PROCESS_UNCATEGORIZED"
    $crash.metadata.product_event_type = "1000"
    (
      re.regex(
        $crash.principal.process.file.full_path,
        `(?i)(w3wp|inetinfo|httpd|apache2|sqlservr|named|mysqld|postgres|nginx|vsftpd|sshd|lsass|spoolsv|dns\.exe|tomcat)`
      )
      OR re.regex(
        $crash.metadata.description,
        `(?i)(Exception code:\s*)(0xc0000005|0xc000001d|0xc00000fd|0xc0000409|0xc0000374|0x80000003|0xc0000096)`
      )
    )
    $crash.principal.hostname = $target_host
    $crash.principal.process.file.full_path = $faulting_app

  match:
    $target_host, $faulting_app over 30m

  outcome:
    $crash_count = count_distinct($crash.metadata.event_timestamp.seconds)
    $exception_codes = array_distinct($crash.metadata.description)
    $first_crash = min($crash.metadata.event_timestamp.seconds)
    $last_crash = max($crash.metadata.event_timestamp.seconds)
    $crash_interval_secs = max($crash.metadata.event_timestamp.seconds) - min($crash.metadata.event_timestamp.seconds)
    $is_rapid_reexploit = if(
      count_distinct($crash.metadata.event_timestamp.seconds) >= 3
      and (max($crash.metadata.event_timestamp.seconds) - min($crash.metadata.event_timestamp.seconds)) <= 1800,
      true, false
    )
    $alert_severity = if(
      $is_rapid_reexploit = true
      and re.regex(
        array_to_string(array_distinct($crash.metadata.description), ","),
        `(?i)(0xc0000005|0xc000001d|0xc00000fd|0xc0000409|0xc0000374|0x80000003|0xc0000096)`
      ), "Critical",
      if(count_distinct($crash.metadata.event_timestamp.seconds) >= 5, "High", "Medium")
    )

  condition:
    #crash >= 2
}
high severity medium confidence

Google Chronicle YARA-L 2.0 rule detecting exploitation-based denial of service via repeated Windows Application Error crashes (Event ID 1000). Correlates crashes of the same application on the same host within a 30-minute sliding window using Chronicle's built-in event grouping. The rule targets PROCESS_UNCATEGORIZED events with product_event_type 1000, filtering on exploit-relevant exception codes in the event description and critical service process paths. Severity outcome logic mirrors the KQL/SPL reference: Critical for rapid re-exploitation with exploit exception codes, High for ≥5 crashes or critical+exploit combination, Medium otherwise. Chronicle must be configured to ingest Windows Application Event Logs via the Windows Event Log parser (microsoft_windows or equivalent log type).

Data Sources

Windows Application Event Log (Event ID 1000) via Chronicle forwarder or Windows Event ForwardingGoogle Chronicle UDM PROCESS_UNCATEGORIZED events with product_event_type=1000Chronicle Windows Event Log parser (log type: WINEVTLOG or MICROSOFT_WINDOWS)

Required Tables

UDM events (PROCESS_UNCATEGORIZED type, product_event_type 1000)

False Positives & Tuning

  • Containers or VMs running crash-test harnesses (AFL fuzzer, libFuzzer) against locally compiled test targets — these generate high-frequency crash events with genuine exploit exception codes (0xc0000005, 0xc000001d) but against test binaries, not production services.
  • Windows Update or cumulative patch installation causing IIS, SQL Server, or DNS service restarts in rapid succession, with the old process instances generating Event ID 1000 entries during forced teardown.
  • Elastic APM, Dynatrace, or AppDynamics agents hooking into critical service processes and triggering structured exception handling during initialization, producing 0xc0000005 exception codes in application error events that are self-resolving.
Download portable Sigma rule (.yml)

Other platforms for T1499.004


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Application Crash with Access Violation (Event ID 1000)

    Expected signal: Windows Application Event Log: Event ID 1000 with Source='Application Error', FaultingApp containing 'powershell.exe', ExceptionCode '0xc0000005'. Windows Error Reporting Event ID 1001 may also fire. Sysmon Event ID 1 (Process Create) for the spawned child powershell.exe with the Marshal::ReadInt32 command line, followed by Sysmon Event ID 5 (Process Terminate) with non-zero exit code.

  2. Test 2Service Crash Loop Simulation (Event ID 7034 / Rapid Restart Pattern)

    Expected signal: Windows System Event Log: Event ID 7000 (service failed to start) or 7034 (service terminated unexpectedly) for ArgusTestDoSSvc across three attempts within approximately 10 seconds. Each start attempt will fail and log a separate event. The SCM logs the service name, failure count, and timestamp.

  3. Test 3BIND9 DNS Service Crash Simulation via Malformed TKEY Query (CVE-2015-5477 Pattern)

    Expected signal: On unpatched BIND9: /var/log/syslog or journalctl -u named will show 'named[PID]: INSIST(...)' assertion failure followed by process termination and systemd restart. On patched systems: query will be rejected (REFUSED or NOTAUTH) with no crash. Sysmon for Linux: process execution of dig with TKEY arguments logged via auditd or eBPF sensor.

  4. Test 4Web Server Malformed Request Crash Simulation (Heap Exhaustion / Buffer Overflow Pattern)

    Expected signal: Sysmon Event ID 3 (Network Connection): outbound connections from python3 to localhost:80 logged. If web server is vulnerable: Application Event ID 1000 (Windows) or syslog SIGSEGV for the worker process. Web server access/error logs will show malformed requests. The connection-to-crash temporal correlation (within 5 minutes) activates the hunting query joining DeviceNetworkEvents with crash events.

Unlock Pro Content

Get the full detection package for T1499.004 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections