The watchmen are being watched, and they don't know it.
Unit 42 published "Blinding the Watchmen" tonight — original threat research from Yahav Festinger documenting a live adversary technique observed in active campaigns. No CVE. No patch. The vulnerability is the architecture itself.
The core observation is this: cloud logging services aren't just your observability layer. In the hands of an attacker with valid IAM credentials, they're a reconnaissance tool and a evasion platform simultaneously. The attacker's calls look exactly like your own monitoring stack. That's the design.
The three abuse patterns Unit 42 documents are worth sitting with.
First: log disablement during the operation window. AWS CloudTrail, Azure Monitor, and GCP Cloud Logging all permit IAM-privileged actors to pause or stop logging. Disable, move laterally, stage data, exfil, re-enable. The gap can be seconds to minutes. Most SIEM alerting on log volume drops runs against a minimum threshold — attackers calibrate the window to stay under it. Clean entry, clean exit.
Second: log reading for defender visibility mapping. Before the operation, the attacker queries the logging configuration to understand precisely what is and isn't being captured. Which S3 buckets have CloudTrail data event logging enabled? Which API calls are excluded from the trail? Every one of those queries is a legitimate read-only API call. None of them generate alerts by themselves. The attacker walks out with a precise map of your blind spots, built entirely from your own infrastructure.
Third: cross-tenant logging API abuse. In multi-account AWS orgs or Azure tenant federations, a compromised logging identity can enumerate other tenants' log configurations — yielding reconnaissance on targets not yet directly compromised. The escalation path from "we have one AWS account" to "we know the logging posture of the entire organization" runs through legitimate API calls. The logging layer was on the honor system, apparently.
The MITRE mapping is clean: T1526 (Cloud Service Discovery) for the visibility enumeration, T1562.008 (Impair Defenses: Disable Cloud Logs) for the disablement window, T1530 (Data from Cloud Storage) for reading the log buckets as intel. The kill chain dependency matters — this technique requires prior credential compromise. T1078.004 is the prerequisite. Unit 42 observed it following IAM credential theft via phishing and exposed access keys. Both are commodity attacks in 2026. It always does come back to the credential.
The architectural problem underneath all of this is that cloud logging was designed assuming the entity with logging IAM permissions is the defender. There is no native write-only logging mode in CloudTrail or Azure Monitor — the same identity that can read logs can modify logging configuration. The attacker who steals those credentials inherits that assumption wholesale. That's not a bug in the traditional sense. It's a design premise that didn't account for credential compromise as the entry point.
Blast radius is every cloud-native org running SOC operations that depend on cloud-native logging without compensating controls. AWS, Azure, GCP — all three documented. Provider-agnostic, because the technique exploits a shared architectural pattern, not a vendor-specific flaw.
No patch closes this. The mitigations are architectural and operational. Route logs to a write-only sink owned by a separate identity that your production IAM cannot touch — AWS S3 Object Lock in Compliance mode is the implementation. Alert on logging configuration changes immediately, not on threshold: any StopLogging, DeleteTrail, UpdateTrail, or equivalent Azure/GCP call should fire regardless of duration. The attacker counts on your threshold being set too high. Alert on log reads by non-SOC identities — T1530 is the recon step, and most orgs alert on writes while watching nothing on reads. Separate the logging IAM principal from the operator IAM principal; your on-call SRE and your logging configuration identity should not share credentials. And if you run a multi-account org, audit which identities can read logging configurations across accounts — the cross-tenant reconnaissance path is the one most orgs haven't modeled.
Unit 42 is explicit: this was observed in active campaigns. Not derived from theoretical analysis. The exposure window is open right now for any org that hasn't separated logging identity from operator identity and hasn't set zero-tolerance alerting on logging configuration changes.
The defenders assumed the logs were theirs. They weren't.