A SOC analyst at a mid-sized SaaS shop opens her CloudTrail console on a Tuesday morning, hunting for evidence of a flagged login from the night before. The console is clean. Suspiciously clean. The API call that disabled logging for that region fired forty-five seconds before the suspicious activity she was sent to investigate. The receipts were turned off before the crime, and her cybersecurity program has no idea what it didn’t see.

That scenario is no longer hypothetical. Palo Alto’s Unit 42 published research this week documenting the techniques attackers are using to manipulate cloud logging services for defense evasion, and the playbook is depressingly straightforward. Disable the trail. Reroute the destination. Encrypt with a key the defender doesn’t hold. Move laterally with the lights off.

The audit trail is now the attack surface

For years, security teams treated logging as a checkbox. You enabled CloudTrail, Azure Monitor, GCP Audit Logs, shipped them to a SIEM, and assumed any attacker who reached your environment would leave footprints in those telemetry streams. That assumption is dying.

Unit 42’s research walks through scenarios where threat actors with valid credentials in a cloud tenant target the logging infrastructure itself. Disabling a trail is a documented API call. So is changing the destination bucket. So is rotating the KMS key that encrypts the logs. Each of these operations generates its own log entry, sure, but only if a higher-level trail or a separate monitoring account is still recording. Most organizations don’t have that second layer. They built one logging configuration, ticked the SOC 2 box, and moved on.

The thing that makes this dangerous is the gap between “logs exist” and “logs are trusted.” A defender chasing a brute-force burst across a federated identity provider, or trying to figure out which storage objects were accessed during a forty-minute window, will rebuild the timeline from the audit trail. If the trail stopped recording at minute three, the rebuild fails silently. No error message. Just nothing.

Microsoft is publishing playbooks because investigators are stuck

The same week Unit 42 was documenting log evasion, Microsoft’s security blog dropped a structured playbook for reconstructing AI activity inside Microsoft 365 Copilot and Azure AI services. The framing is telling. Microsoft is documenting how to stitch together Copilot prompt logs, Purview audit events, identity sign-ins, and tenant-level diagnostics into something that resembles a coherent narrative, because investigators are getting handed Copilot data-exposure incidents with no idea where to start.

The Copilot problem is the cloud logging problem in new costumes. AI agents touch identity, data, and tools across surfaces that emit telemetry into different stores with different retention windows and different access controls. An attacker who steals a session token and prompts Copilot to summarize confidential documents leaves a partial trail in three places, none of which by itself tells you what happened. Threat detection in this world demands cross-source correlation, and most teams don’t have the schema awareness to do it.

CISA is changing how it scores risk for a reason

CISA’s binding operational directive this week, telegraphed by acting director Nick Andersen, will direct federal agencies to change how they triage vulnerabilities, elevating some and explicitly deprioritizing others. The agency is conceding that CVSS-driven, treat-everything-equally patch programs have stopped scaling, at the same moment Microsoft is shipping 206 CVEs in a single Patch Tuesday and Dark Reading is openly blaming AI-accelerated bug discovery for the volume.

The connecting thread across these stories is that defenders are running out of signal. Signal from logs is being actively attacked. Signal from AI surfaces is fragmented across vendors. Signal from the CVE pipeline is so loud it has become noise. Incident response that depends on “we’ll check the logs after” is going to fail when the logs are missing or the schema is unrecognizable.

Hardening your cyber security telemetry before the trail goes dark

The defensive work is unsexy and mostly operational. Start by treating your logging configuration as production infrastructure, not background plumbing.

Put your cloud audit logs in a separate account or project with no identity overlap with your workloads. The attacker who compromises your production tenant should not be one IAM role away from your CloudTrail destination. The control plane that creates, modifies, or disables trails should require break-glass approval and emit a dedicated alert, not a SIEM rule competing with ten thousand other events.

Alert on logging-disabled events as a high-severity primary signal. A StopLogging API call, a destination bucket policy change, a KMS key rotation on a logging key, all of these should page somebody. They are nearly always either an attacker action or a sloppy operator action that needs immediate review. The response is the same either way: investigate now.

Build a logging coverage map and check it quarterly. List every cloud account, every region, every workload tier, and what’s recording. The defense in depth posture you assumed you had two years ago is not what your engineering teams shipped last month. New regions, new subscriptions, and new SaaS integrations all create blind spots that nobody owns until something burns.

For AI activity specifically, follow Microsoft’s lead and map your data sources before the incident. Know where Copilot prompt telemetry lives, what your Purview audit retention window actually is, how identity logs correlate with tool invocations, and who has rights to query each store. Your first AI incident response engagement is not the time to discover prompt logs were never enabled.

Treat brute-force telemetry, firewall events, and threat-protection signals from your edge as inputs to the same timeline as your cloud audit trail. The teams that recover quickly from log-tampering incidents are the ones with multiple independent sources of truth. Network flow logs, identity provider events, and EDR telemetry all serve as cross-checks when the cloud-native audit trail goes quiet. Security hardening of the telemetry pipeline matters as much as security hardening of the workload it watches.

Rehearse the scenario. Tabletop an incident where your primary log source stops recording mid-attack. If the answer to “what would you check first” is “I don’t know,” you have the answer to “what to fix next.”

Sources

• Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility
• Reconstructing AI activity in investigations
• CISA to transform how it assesses cyber vulnerabilities and risks, Andersen says
• Blame AI: Patch Tuesday Hits Record 206 CVEs