Weekly Recon #10: Blind Spots

🎯 Attack of the Week: blinding the cloud logs, then reading them

Yahav Festinger at Unit 42, "Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility" [2026-06-09]

How it runs. You land a role with rights over the logging plane, and you have options before you touch anything noisy. Call StopLogging on the CloudTrail trail and the writes stop. Or DeleteTrail, or empty and delete the S3 bucket under it with s3:DeleteObject then s3:DeleteBucket. Prefer something quieter: repoint the trail at a KMS key you control with update-trail, then revoke CloudTrail's access to that key, and delivery fails so new logs stop landing at all. Quieter still, if the trail has log file integrity validation off, pull the log objects with s3:GetObject, edit the JSON to drop your own calls, and put them back with s3:PutObject. The GCP side is the same moves under different names: DeleteSink, logging.buckets.delete, a CMEK swap with gcloud logging buckets update --cmek-kms-key-name.

The same rights cut the other way. The permissions that create and reconfigure trails, the ones that go beyond stopping them, let you stand up a fresh trail or a logging sink that ships to a bucket you own, or repoint the existing trail's --s3-bucket-name with update-trail, and now the victim's control-plane activity streams to you. Logging is a two-way mirror, and the rights to reshape it are the rights to sit behind it and watch the response.

Ship This Week.

• Lock down who can change the logging plane. Scope cloudtrail:StopLogging, DeleteTrail, UpdateTrail, CreateTrail, and s3:DeleteBucket / s3:PutBucketPolicy on the trail's bucket. On GCP, lock logging.sinks.update, logging.sinks.delete, and logging.buckets.delete.
• Turn on CloudTrail log file integrity validation. With it on, tampering with delivered log files breaks the digest chain, so the quiet edit-and-replace move above stops being quiet.
• The stop, delete, or re-key call is the canary. Alert on any of them as a high-severity event, because in a healthy account they almost never fire.
• Watch for a second trail or sink you didn't create, and for a trail whose destination bucket or KMS key changed. A new sink pointed at an unfamiliar bucket is exfiltration wearing a logging label.

🔧 Defender's Corner: check that your GCP detections survive export

Verify the field your GCP audit-logging detections depend on reaches your SIEM at all. Art Ukshini at Permiso, "Mind the Gap: GCP serviceData in Logs Explorer vs. Exported Logs" [2026-06-16] documents a gap that turns a working detection into a blind one.

serviceData is a deprecated GCP audit-log field, and for some services it still carries the only copy of the signal you need. When someone disables audit logging through SetIamPolicy on cloudresourcemanager.googleapis.com, the field that says this was a removal, the policyDelta with action: REMOVE, service: allServices, and the affected logType, lives inside serviceData.policyDelta. That field renders in Logs Explorer. For this event, GCP drops it from the exported log record, so it never reaches your analytics platform. Same insertId, same method, the discriminating field gone. Your rule can no longer tell enabling audit logging apart from disabling it, so the call that goes dark in the Attack above slips through as routine. The rule keeps reporting healthy coverage it no longer has.

For your engineer: take your top GCP detections, find each that reads a serviceData sub-field, and confirm that field survives export into your SIEM. Where it lands only in Logs Explorer, rebuild the rule on a field that survives.

The same failure shows up in AWS. Know what you lose before you move CloudTrail off Lake. AWS deprecated CloudTrail Lake for new customers on June 1 and points you to CloudWatch instead. Aidan Steele, "CloudTrail in CloudWatch isn't very good" [2026-06-19] ran the migration and found the CloudWatch destination drops enrichment the trail and Lake carried. Lake enriched events with resource tags and global condition keys, and that enrichment is gone in CloudWatch, so a rule scoped on a tag or an aws: condition key has nothing left to match. Events also land about 8 hours late where a trail delivers in minutes. Before you migrate, list every detection that reads a tag or a condition key and confirm it still fires on the CloudWatch copy.

🚨 Rule of the Week: catch the ransomware that logs like a normal write

Jonah Feldman at Datadog Security Labs, "Holding blobs for ransom: Four methods for Azure Storage ransomware" [2026-06-15] names the detection gap directly: Azure resource logs don't capture the x-ms-encryption-key-sha256 header, so a customer-provided-key (CPK) PutBlob and an ordinary PutBlob look identical in the log.

You can't key on the header, so key on the behavior around it. Alert when one principal overwrites a large number of existing blobs in a short window, and raise the severity when that burst pairs with control-plane moves that lock the data: a new encryption scope, a storage account default-encryption (CMK) change, or a Key Vault key or vault deleted minutes after the writes. The bulk-overwrite-then-delete-the-key shape is the ransom, even when each individual PutBlob reads clean.

🤖 Agent Bench: hand the first audit pass to an agent

The blind spots above live in your logs. The other one is in code you depend on and have never read. Reading a dependency's source for injection and unsafe deserialization by hand is slow, so it rarely gets done. An agent can run the first pass and hand you somewhere to start. Treat that pass as a head start, and verify everything it claims before you act on it.

Scope the target precisely: the repo URL, the exact commit SHA or release version, the language and framework, and the paths to exclude. An undefined target gives you an undefined audit.

Ask the agent to hunt the code-audit classes: injection, auth bypass, SSRF, path traversal, and unsafe deserialization. Run secrets-in-code as a separate deterministic scan, since a grep-based scanner beats a reading pass for that. For every hit, require a source-to-sink trace: the reachable entrypoint, the attacker-controlled input, and the guard conditions the model believes are missing. A finding without that trace is a guess.

What you walk away with: a ranked list you can turn into a disclosure draft after your own validation, once the false positives are stripped.

This is the oss-security-audit workflow, built for cloud security OSS.

Honest caveat: agents over-report, and severity inflation is the least of it. They fabricate reachability, invent control flow, and miss the mitigating check three lines up. Your verification is the gate.

Try it this week: pick one dependency in your stack you have never read. Pin the version, run the audit, and verify the top finding's source-to-sink trace yourself.

📡 Also on the Radar

Katie Knowles at Datadog Security Labs, "Entra Agent ID: The blueprint blast radius" [2026-06-11]. Entra's new agent-identity model hangs many identities off one object. A blueprint is an app registration for AI agents, and it is the single trusted source of authentication for everything beneath it: a blueprint principal in each tenant, up to 250 agent identities per tenant under that, plus optional agent users. Add one credential to the blueprint and you can mint tokens that impersonate any identity it anchors, through a client_credentials exchange with an fmi_path naming the target. Where a blueprint deploys agents across tenants, that one credential reaches all of them, which is the shape of the Midnight Blizzard third-party compromise Knowles draws the line to. The blast radius of a single secret is the part you can't see from inside one agent. Worth tracking as agent identities multiply faster than the IAM model around them.

💼 Recon Roles

Senior Security Engineer (AI Platform) · Chainguard

A brand-new individual-contributor role that reads less like infrastructure security and more like governing the AI tooling the rest of the company runs on. The scope: administer Claude and ChatGPT at the org level, manage console settings through Git, run API key lifecycle, build anomaly detection for AI spend by team, write MCP servers and agentic tooling in Python or TypeScript, and keep sensitive data out of prompts. Five-plus years and hands-on enterprise Claude or ChatGPT administration expected, on GCP. The US listing posts $130,000 to $160,000 USD, modest for a senior security title at a company with Chainguard's name; the Canada listing shows no range. Worth a look if AI platform posture is the job you want before every org writes the same req.

US + Canada remote. Verified open as of Mon 2026-06-22. Apply: US or Canada

Roles can close anytime. No affiliation or payment. Found one already closed? Reply and tell me.

The cloud doesn't hide things from you out of malice. The defaults do it: a deprecated field that stops at the console, a header that never reaches a log, a logging plane any sufficiently privileged role can switch off. Assume your visibility has holes, then go find which detection breaks when the one field you counted on never arrives.

Know someone who'd want this in their inbox? Forward it to them.

Full post with source links: defensive.works/recon/issue-10

// end of issue 010

Sponsored content may appear below. Not part of Weekly Recon editorial.