Varonis found that anonymous S3 requests via VPC endpoints were invisible to CloudTrail. AWS added logging. But logging is reactive — by the time you see the entry, the attacker's upload is complete. The endpoint policies that allow the attack are still wide open.

Forensic evidence doesn't undo a breach

In April 2026, Varonis Threat Labs disclosed a finding that should concern every organization running VPC endpoints for S3: anonymous requests made through VPC endpoints did not appear in CloudTrail Network Activity events. Regardless of whether the bucket's permissions allowed or denied the request — no logs.

An attacker who compromised an application server inside a private VPC could use the existing VPC endpoint to connect to an external S3 bucket they controlled. Upload sensitive data. Download malware. All without generating a single log entry in the source account.

AWS responded by patching CloudTrail to log anonymous API requests via VPC endpoints as Network Activity events. The industry treated this as resolution.

It isn't. A murder has occurred. AWS's patch ensures there's now forensic evidence at the scene — fingerprints, DNA, security camera footage. That evidence helps investigators reconstruct what happened. It doesn't bring the victim back. It doesn't prevent the next crime.

Logging is forensics. The breach already happened. The data already left your account. The attacker already has it. The log entry tells you what was taken, when, and through which endpoint — after the fact. Your incident response team writes a better post-mortem. Your data is still gone.

The VPC endpoint policies that allow the attack — permissive defaults, no anonymous-request deny, no bucket restriction — are unchanged by the patch. These prevent the crime. And they're still wide open in most accounts.

1. Two misconfigurations enable the attack. A third makes it invisible.

The Varonis scenario has two layers — the attack itself and the evasion of detection. They're different problems with different fixes.

The attack requires two conditions:

The VPC endpoint policy didn't deny anonymous requests. Most organizations deploy VPC endpoints for S3 with default or permissive policies. The default policy allows all actions by all principals — including unsigned, anonymous requests. Unless the endpoint policy explicitly denies requests without authentication, anonymous access passes through.

The VPC endpoint policy didn't restrict target buckets. Without a Resource restriction in the endpoint policy, any S3 bucket globally — including attacker-controlled buckets — is reachable through the organization's endpoint. The endpoint becomes a bidirectional channel to the entire S3 namespace.

These two misconfigurations are the attack surface. Fix either one and the attack fails — deny anonymous requests OR restrict target buckets. The attacker can't exfiltrate data if they can't make anonymous requests, and they can't reach their own bucket if the endpoint restricts targets.

The invisibility requires a third condition:

Network Activity event logging wasn't enabled. Even after AWS's patch, anonymous requests appear as Network Activity events only if the customer has this event type enabled on their CloudTrail trail. Without it, the attack proceeds AND leaves no forensic trail.

But here's what matters: enabling Network Activity logging doesn't prevent the attack. It's installing security cameras in a building with no locks. The cameras record the intruder walking in, taking what they want, and leaving. Excellent footage. The intruder still took everything.

The distinction is fundamental: fixing endpoint policies prevents the breach. Enabling logging documents the breach for your incident response team. Both are necessary. They are not interchangeable. And only one of them keeps your data in your account.

2. What AWS patched vs. what prevents the breach

AWS's response addressed forensics: anonymous API requests via VPC endpoints now generate Network Activity events. Before the patch, the crime was invisible. After the patch, the crime scene has evidence.

Evidence doesn't prevent crime. The distinction:

AWS patched one forensics row. The three prevention rows — the ones that stop data from leaving — are configuration you own, unchanged by the patch.

An organization that enables logging will have a well-documented breach report. An organization that fixes its endpoint policies won't need one.

3. Detecting the misconfigurations that enable the crime

Prevention means finding the unlocked doors before the intruder walks through them. Five controls detect the component conditions — each a YAML predicate the evaluation engine processes. The controls identify which doors are open so they can be locked. No Varonis-specific engine code; the same engine that evaluates 700+ other security controls processes these identically.

Endpoint anonymous access. A control checks whether the VPC endpoint policy explicitly denies unsigned requests. If it doesn't, the endpoint allows anonymous S3 access — the first link in the attack.

The finding tells the operator exactly what's wrong:

DEFECT:
  The VPC endpoint policy does not deny anonymous
  (unsigned) requests. Unauthenticated S3 requests
  can transit the endpoint without identity
  information.

DELTA:
  Change: endpoint policy denies anonymous
  Current: false
  Fix: set to true (enable)

The DELTA section is mechanically derived from the control's predicate — it tells the operator the specific configuration change that eliminates this finding. Not generic advice; a verified counterfactual.

Endpoint target bucket restriction. A second control checks whether the endpoint policy restricts which S3 buckets are reachable. Without this restriction, the endpoint is a channel to any bucket globally — including attacker-controlled ones.

Endpoint IAM conditions. A third control checks whether the endpoint policy requires IAM conditions (aws:PrincipalArn or aws:PrincipalOrgID) on all requests. Without conditions, any principal — including anonymous ones — can use the endpoint.

Network Activity event logging. A fourth control verifies that CloudTrail Network Activity events are enabled. Without this, the organization has no forensic trail even after AWS's patch — anonymous requests complete successfully and leave no record. Enabling logging doesn't stop the attack; it produces evidence for post-breach investigation.

Anonymous access alerting. A fifth control verifies that CloudWatch alarms are configured to detect anonymous VPC endpoint requests. Even with logging enabled, without alarms the log entries sit unread — the breach is documented but nobody is notified.

The compound chain. Three of the five controls compose into a chain representing the full Varonis scenario. The chain fires when all three member controls find issues on related assets — the attack surface is open AND invisible:

Chain: vpc_endpoint_evasion
  Escalation threshold: 3 (all must fire)
  Members:
    1. Endpoint allows anonymous requests
    2. Endpoint allows any target bucket
    3. No Network Activity event logging

The chain models the complete Varonis disclosure: anonymous requests pass through the endpoint (member 1), reach any bucket including attacker-controlled ones (member 2), and leave no log entries (member 3). Findings on the chain get a ChainBonus multiplier on their ExposureScore, surfacing them above individual findings.

The prevention/forensics distinction still applies to the operator's response: fixing either endpoint policy control (member 1 or 2) prevents the breach; enabling logging (member 3) helps investigate if prevention fails. The chain surfaces all three together so the operator sees the full picture and locks the doors before worrying about the cameras.

4. What the operator sees — and does

An operator running the scan against their VPC infrastructure sees the full context per finding — not just "something is wrong" but the complete chain from misconfiguration to consequence, with the specific change that prevents the breach:

DEFECT — what specifically is misconfigured. The unlocked door. Mechanically derived from the control's predicate against their actual observation data.

INFECTION — how the misconfiguration enables attack. What happens if the door stays unlocked. Authored per control, explaining the specific mechanism.

FAILURE — worst-case outcome. What the attacker achieves.

OBSERVED — which properties the engine consulted. The operator can verify the finding against their own configuration.

DELTA — the minimum change that prevents this specific breach path. Not generic advice — a verified counterfactual. "Change this property from X to Y and this finding disappears." The operator applies the delta, re-runs, confirms the door is locked.

The operator doesn't research the vulnerability. They don't read the Varonis disclosure to understand the attack path. They don't manually inspect their VPC endpoint policies. The finding carries the context to decide and the delta to act. Prevention happens at the terminal, not after a research cycle.

5. Why compound detection matters here

A scanner that checks VPC endpoint policies individually might flag "endpoint policy is permissive" as a medium-severity finding. An operator with 200 security findings triages it below the critical and high items. It sits in the backlog.

But "permissive endpoint policy" alone doesn't convey the risk. The risk is "permissive endpoint policy AND unrestricted bucket targets" — together enabling data exfiltration through the endpoint. Add "no Network Activity logging" and the exfiltration is invisible. Each component is low-to-medium severity alone. Together they're an undetectable exfiltration channel.

Compound chain detection surfaces the combination. The three chain-member findings are linked, their ExposureScores are boosted by ChainBonus, and the operator sees them as one triage unit.

The operator's response follows the prevention/forensics layers:

Prevention: "Fix either endpoint policy control to prevent the breach. Deny anonymous requests OR restrict target buckets. Either one locks the door the attacker would walk through."

Forensics: "Enable Network Activity logging and configure alerts. If prevention fails or another path exists, this gives your incident response team the evidence to scope the damage. It doesn't prevent the damage."

Prevention first. Forensics as the fallback. The chain surfaces both so the operator addresses prevention before spending time on logging configuration.

6. Prevention at catalog speed, not code speed

The implementation for the Varonis scenario contains zero engine modifications. Five YAML control definitions, five triage override files, one chain definition, and ten test fixtures. The evaluation engine processes them identically to every other control in the 700+ control catalog.

This matters because novel attack vectors appear continuously. If responding to each one required custom engine code — new parsers, new evaluation paths, specialized handling — prevention would lag behind disclosure by weeks or months. Instead, the catalog is the extension mechanism. A new attack vector means new YAML files describing what to prevent, not new Go code changing how prevention works.

The Varonis disclosure was published. Within the same development cycle, five controls detecting every component of the attack were authored, tested, and deployed. The engine that runs them didn't change. Prevention keeps pace with disclosure because the catalog is the boundary, not the codebase.

7. The configuration lifecycle

The Varonis disclosure illustrates a pattern that repeats across cloud security:

1. A platform capability (VPC endpoints) ships with permissive defaults
2. Organizations adopt it without tightening the defaults
3. A researcher discovers the permissive configuration enables attack
4. The platform patches the forensics layer (logging)
5. The underlying misconfiguration remains the customer's responsibility

Steps 1-4 happen once. Step 5 is ongoing. Every VPC endpoint deployed before the organization learns about this disclosure has the default permissive policy. Every new endpoint deployed by a team that hasn't updated their templates inherits it.

Prevention that runs continuously — not once after reading a disclosure but on every scan — catches both existing misconfigurations and new ones introduced by teams deploying endpoints without the updated policy. The scan finds the unlocked doors before the attacker does. That's the difference between prevention and forensics: prevention is proactive and repeatable. Forensics is reactive and too late.

8. Applying this to your environment

Two actions prevent the breach. Two actions help you investigate after one.

Prevent: Audit your endpoint policies. Check whether each endpoint's policy explicitly denies anonymous requests and restricts target buckets to your organization's S3 resources. Default policies don't include either restriction. Fixing either one prevents the Varonis scenario entirely — an attacker can't exfiltrate anonymously through an endpoint that requires authentication, and can't reach their own bucket through an endpoint that restricts targets. This is the lock on the door.

Prevent: Add IAM conditions. Require aws:PrincipalArn or aws:PrincipalOrgID on endpoint policies. This ensures every request through the endpoint carries verified identity — closing the anonymous access path at the policy layer. No identity, no access.

Investigate (after the fact): Enable Network Activity events. Verify your CloudTrail trails are configured to log Network Activity events for VPC endpoints. This doesn't prevent anything — the data leaves before the log is written. But when prevention fails (misconfigured endpoint, new attack path, insider threat), the forensic trail is the difference between "we know what was taken" and "we have no idea."

Investigate (after the fact): Monitor for anonymous access. Configure CloudWatch metric filters or EventBridge rules to alert on anonymous requests through VPC endpoints. Logging without monitoring means nobody reads the evidence until the breach is discovered through other means — customer complaints, dark web listings, regulatory notification.

Prevention keeps your data in your account. Forensics helps you write the incident report. Do both. But if you can only do one thing today, fix the endpoint policies.

The uncomfortable truth

AWS's patch was necessary. Before it, the attack was invisible. After it, the attack is logged. That's progress — from no evidence to forensic evidence.

But forensic evidence doesn't undo a breach. The crime has occurred. The data is gone. The attacker has disappeared. Your incident response team has excellent logs to reconstruct what happened. They can tell you exactly which endpoint was used, which bucket received the data, and when the exfiltration completed. The post-mortem will be thorough. None of it brings the data back.

Security tools that focus on logging and alerting are building better forensics. They help you investigate faster. They don't prevent the breach.

Prevention means finding the misconfigured endpoint policy before the attacker does. Identifying that anonymous requests are allowed before they're exploited. Flagging the unrestricted bucket target before data transits through it. Prevention is the lock on the door. Forensics is the camera that records someone walking through an unlocked one.

AWS fixed the camera. The doors are still unlocked. That's the gap this tool closes.

Prevention for the Varonis "Invisible Footprint" scenario is implemented in Stave, an open-source security CLI that finds misconfigurations before attackers do. Five controls detect the unlocked doors. The vpc_endpoint_evasion chain surfaces them as one triage unit so teams fix the prevention gaps first.