Detecting Defense Evasion: When Attackers Go After Your Logs First

If an attacker can turn off your logging before they touch anything else, everything downstream of that moment is a blind spot — not a detection gap you can backfill later.

Why this is the detection to prioritize right now

Two things converged in the last few weeks that make this worth acting on. Palo Alto’s Unit 42 published research on attackers abusing cloud logging services directly for defense evasion — not just as a side effect of an attack, but as the first move. And AWS’s own Threat Technique Catalog update in June added new entries built from patterns its CIRT team is seeing in real incidents, including compute hijacking and evasion of workload-level controls.

Separately, incident response firm Sygnia documented an AI-assisted attacker chain that moved from initial access to source control, CI/CD, and runtime services in about 72 hours. The individual techniques weren’t new — credential theft, secrets harvesting, discovery, persistence. What changed is the speed. A detection that used to catch an attacker on day three now has to catch them in the first hour, because there might not be a day three before they’re out.

Both stories point at the same architectural weak point: most SIEM deployments monitor what attackers do with access, but treat tampering with the logging pipeline itself as a low-priority edge case. That’s backwards. If you only build detections for the interesting stuff — root logins, privilege escalation, data exfiltration — and skip the boring API calls that disable the collection of those signals, an attacker who reads the same threat research you do will just turn the lights off first.

This is MITRE ATT&CK T1562.008 — Impair Defenses: Disable or Modify Cloud Logs, and it’s one of the highest-value, lowest-effort detections you can add to a cloud SIEM.

The short version

The API calls to cover

Attackers going after AWS logging infrastructure converge on a small set of actions across four services. Build detections for all four — covering only CloudTrail and missing GuardDuty or the log bucket itself leaves the same gap with a different name.

None of these are exotic. They’re standard, well-documented API calls that show up in CloudTrail’s own event history — which is exactly why they’re detectable with almost no false-positive tax.

A Sigma rule that covers the CloudTrail piece

title: AWS CloudTrail Logging Disabled or Narrowed
id: 4b2e7f1a-6c3d-4e9a-9b21-7f4e6a2d8c33
status: stable
description: Detects CloudTrail being stopped, deleted, or scoped down — a common precursor to further attacker activity going unlogged.
references:
    - https://attack.mitre.org/techniques/T1562/008/
author: Xpernix Detection Engineering
date: 2026-07-21
tags:
    - attack.defense-evasion
    - attack.t1562.008
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: cloudtrail.amazonaws.com
        eventName:
            - StopLogging
            - DeleteTrail
            - UpdateTrail
            - PutEventSelectors
    condition: selection
falsepositives:
    - Planned trail reconfiguration during infrastructure changes — should still be reviewed, just expected
level: critical

Compile it straight to a real-time query the way you would any other Sigma rule:

sigma convert -t splunk -p aws rules/cloudtrail_logging_disabled.yml

(eventSource="cloudtrail.amazonaws.com") AND (eventName IN ("StopLogging", "DeleteTrail", "UpdateTrail", "PutEventSelectors"))

Write matching rules for the GuardDuty, VPC Flow Logs, CloudWatch Logs, S3, and KMS actions in the table above using the same pattern — same logsource.product: aws, different service and eventName list. Five small rules, full coverage.

The part most teams get wrong: where the detection runs

Here’s the failure mode that makes this technique effective even against teams who have a rule for it: if StopLogging is what disables the pipeline, and your only alerting path is “query the pipeline for suspicious events,” the alert depends on the very thing that just got turned off.

Two things fix this:

1. Evaluate this rule in a real-time stream, not a scheduled batch query. StopLogging and DeleteTrail calls are themselves CloudTrail events — they get logged in the seconds before logging actually stops. A rules engine consuming events as they arrive (via EventBridge, a message queue, or a streaming ingest pipeline) catches the tampering event itself, before the gap opens. A scheduled script that queries the log store every 15 minutes might query a store that’s already stopped receiving data.

def check_cloudtrail_logging_disabled(event: dict) -> Optional[RiskMatch]:
    if event.get("event_source") == "cloudtrail.amazonaws.com" and event.get("event_name") in (
        "StopLogging", "DeleteTrail", "UpdateTrail", "PutEventSelectors",
    ):
        return RiskMatch(
            rule_name="cloudtrail_logging_tampered",
            severity="critical",
            summary=f"CloudTrail logging modified: {event.get('event_name')} by {event.get('actor_arn')}",
            labels={"mitre": "T1562.008"},
        )
    return None

2. Alert delivery has to survive the log store being unavailable. If your alert manager only fires on a query against the same database an attacker just disabled ingestion into, route the alert independently — straight from the streaming consumer to your paging/notification layer, not through a second read of the same store.

The general principle: your detection for “the logging pipeline was tampered with” cannot have a hard dependency on the logging pipeline it’s protecting. Treat it the same way you’d treat a dead man’s switch.

A scheduled check as a second layer

Real-time coverage handles the tampering event itself. Pair it with a scheduled check that verifies expected state — because an attacker with enough access can sometimes suppress or race the real-time alert too:

-- alerts if any expected trail isn't actively logging
SELECT trail_name, is_logging, last_delivery_time
FROM cloudtrail_trail_status
WHERE is_logging = false
   OR last_delivery_time < now() - INTERVAL 10 MINUTE

Run this against a config snapshot (GetTrailStatus, DescribeTrails) collected independently of the event pipeline — a cron job that calls the AWS API directly, not a query against ClickHouse. That way, even if both the event stream and the alert-on-event path are somehow bypassed, a periodic “is logging actually still on” check closes the gap within its polling interval.

Final thought

Most detection engineering effort goes toward catching what an attacker does with access — lateral movement, data access, privilege escalation. T1562.008 catches something upstream of all of that: the moment an attacker tries to make sure you never see the rest. It’s a short list of API calls, it has a low false-positive rate, and — per the research prompting this post — it’s actively being used in the wild right now. If you don’t have coverage for it today, it’s worth being the next five rules you write, not the next quarter’s roadmap item.

If you want a second opinion on whether your logging pipeline itself is covered — not just what flows through it — contact us.