GuardDuty S3 Malware Protection plans show ACTIVE but never scan objects - health checks work, scans don't (be gentle, my first post).

Question

## Question

We have two `AWS::GuardDuty::MalwareProtectionPlan` resources in separate member accounts under an AWS Organization. Both plans report `Status: ACTIVE` with empty `StatusReasons`, but neither has scanned any S3 objects since April 26, 2026.

**The unusual fingerprint:** The service IS healthy enough to assume its IAM role every ~30 minutes for health checks (`s3:GetBucketNotification`, `events:DescribeRule`), but it is NOT performing any scan operations (`s3:GetObject`, `s3:PutObjectTagging`). All three scan metrics (`CompletedScanCount`, `FailedScanCount`, `SkippedScanCount`) show zero datapoints - meaning the scan-attempt path is never entered, not even to skip or fail.

### Environment

| Field | Value |
|-------|-------|
| Region | us-west-2 |
| Organization ID | `o-abc1234def` |
| Delegated GD Admin | `111111111111` |
| Affected Account 1 | `222222222222` (dev) |
| Affected Account 2 | `333333333333` (preprod) |
| Plan ID (dev) | `aaaaaaaaaaaaaaaaaaaa` |
| Plan ID (preprod) | `bbbbbbbbbbbbbbbbbbbb` |
| Last successful scan | April 26, 2026 (2 EICAR test files tagged `THREATS_FOUND`) |

### What We've Verified (All Correct)

- **IAM role trust policy**: Trusts `malware-protection-plan.guardduty.amazonaws.com` with `aws:SourceAccount` condition
- **IAM role permissions**: `s3:GetObject`, `s3:GetObjectTagging`, `s3:PutObjectTagging` on `arn:aws:s3:::bucket/*`
- **Bucket configuration**: EventBridge enabled, SSE-S3 encryption, `BucketOwnerEnforced`
- **Bucket policy**: Allows tagging operations for GuardDuty service principal
- **EventBridge rule**: `State: ENABLED`, `MatchedEvents > 0`, `FailedInvocations = 0`
- **Plan status**: `Status: ACTIVE`, `StatusReasons: []`
- **No SCPs blocking**: Only `FullAWSAccess` policy attached
- **Free tier**: Account created Feb 2026, well within 12-month free tier
- **CloudTrail**: No configuration changes around April 26-27

### The Diagnostic Fingerprint

| Signal | Expected (Working) | Actual (Broken) |
|--------|-------------------|-----------------|
| EventBridge `MatchedEvents` | >0 | >0 ✓ |
| EventBridge `Invocations` | = MatchedEvents | = MatchedEvents ✓ |
| EventBridge `FailedInvocations` | 0 | 0 ✓ |
| CloudTrail `sts:AssumeRole` | Present | Present ✓ (every ~30 min) |
| CloudTrail `s3:GetObject` by scan session | Present | **Zero** ✗ |
| CloudTrail `s3:PutObjectTagging` by scan session | Present | **Zero** ✗ |
| `CompletedScanCount` metric | >0 | **Zero** ✗ |
| `FailedScanCount` metric | varies | **Zero** ✗ |
| `SkippedScanCount` metric | varies | **Zero** ✗ |
| S3 object `GuardDutyMalwareScanStatus` tag | Present | **Never lands** ✗ |

### Reproduction

```bash
TS=$(date +%s)
KEY="test/smoke-${TS}/uploads/manual/smoke.txt"
printf "test %s" "$TS" > /tmp/gd-smoke.txt
aws s3 cp /tmp/gd-smoke.txt "s3://YOUR-BUCKET/${KEY}"
sleep 90
aws s3api get-object-tagging --bucket YOUR-BUCKET --key "$KEY"
# Expected: GuardDutyMalwareScanStatus tag
# Actual: Empty TagSet
```

### CloudTrail Evidence

Role assumptions by `malware-protection-plan.guardduty.amazonaws.com` occur regularly:
```
2026-05-14T14:11:58Z - AssumeRole SUCCESS
2026-05-14T14:43:25Z - AssumeRole SUCCESS
```

But filtering CloudTrail by the assumed session name (`GuardDutyMalwareProtection`) shows ONLY:
- `s3:GetBucketNotification`
- `events:DescribeRule`

**No `s3:GetObject` or `s3:PutObjectTagging`** - the operations required for actual scanning.

### What We've Tried

1. Enabled `malware-protection.guardduty.amazonaws.com` org service access - no change
2. Enrolled accounts as GuardDuty members under delegated admin - no change
3. Deleted and recreated the MalwareProtectionPlan via CloudFormation - no change
4. Verified both affected accounts exhibit identical behavior
5. Confirmed scans DID work on April 26 (found 2 objects with `THREATS_FOUND` tags from that date)

### Questions

1. Is there a server-side state or flag that could cause the scan-attempt path to be bypassed entirely while health checks continue to work?

2. Is there a free-tier behavior where scans stop (rather than billing) when limits are approached, even though we've only scanned 2 tiny files?

3. Is there any account-level or organization-level setting we might be missing that gates S3 Malware Protection scans specifically (separate from the detector/member configuration)?

4. Could this be related to how standalone `MalwareProtectionPlan` resources interact with the delegated administrator model?

We've exhausted customer-side troubleshooting and the fingerprint (health checks work, scans don't, zero metrics across all three counters) suggests something internal to the service.

---

## Tags
`amazon-guardduty`, `s3`, `malware-protection`, `aws-organizations`

Florian Turnwald · Answer

**Check these 3 specific "Silent Drop" scenarios:**

1. **EventBridge Suffix/Prefix Filtering:** Check your AWS::GuardDuty::MalwareProtectionPlan resource for a S3ObjectKeyFilter. If your manual smoke test path (test/smoke...) doesn't strictly match the prefix/suffix defined in the plan, EventBridge triggers, but GuardDuty silently drops the event before the scan logic starts.

2. **Storage Class & Object Size:** Ensure your test objects are **S3 Standard** or **Standard-IA**. Objects moved to **Glacier** or **Deep Archive** (even via Lifecycle) or objects that are **0 Bytes** are ignored by the engine and often don't even register as SkippedScanCount.

3. **Delegated Admin (DA) Conflict:** Even with "FullAWSAccess", check if the **Delegated Admin account (111111111111)** has a conflicting "Auto-enable" setting for Malware Protection. If the DA settings were updated around April 26, it can override local standalone plans in member accounts, causing a silent execution failure.

**Diagnostic Tip:** Since your metrics are dead zero (not even Skipped), the issue lies in the **routing layer**. If points 1 & 2 are verified, this is likely a backend synchronization issue between the GuardDuty Org-Configuration and your standalone CloudFormation plans - only AWS Support can reset that internal state.

John H · Answer

Got an update from the GuardDuty service team - they've identified the root cause, and the good news is it's something we can fix on our side.  Going to run with this and will let the thread know.  Shout out to Said Gomez, our account exec for getting visibility for us.  We have decided to sign up for official support.

Root Cause: Invalid prefix configuration

The protection plans on both accounts have prefixes configured using wildcard patterns:

*/*/uploads/
*/*/attachments/
*/*/tool-results/
*/*/analysis/
The issue is that S3 Malware Protection does not support regex or wildcard-based prefix matching — it only accepts literal prefix strings. Because the configured prefixes are invalid, the scan engine never matches any uploaded objects, which is why all scan metrics show zero.

Why it appeared to work before April 26:

The service team clarified that this isn't a "zombie plan" or backend sync issue. It's likely that objects uploaded before April 26 happened to land in paths that coincidentally matched, or the prefix configuration was different at that time.

Fix:

Update your MalwareProtectionPlan prefix configurations to use literal path strings instead of wildcards. For example, if your bucket structure is:

s3://trblsm-agent-workspace-dev/workspace1/project1/uploads/

You'd configure the prefix as: workspace1/project1/uploads/

If you need to cover multiple paths, you'll need to list each literal prefix individually.

Florian Turnwald · Answer

This is a textbook "Zombie Plan" scenario: the Control Plane reports green, but the Data Plane workers never receive the trigger. Given your evidence that it previously worked and stopped without changes, you are likely facing a backend event-routing synchronization issue in us-west-2.

**Regarding escalation:**

* **my honest recommendation:** For production environments or solvent business cases, I always recommend a **Business Support Plan**. It is the only guaranteed way to open a high-priority ticket and have a Cloud Support Engineer manually reset the internal service state.

* **"No-Cost" Gamble:** Beyond a paid plan, there are no "secret tricks" to force an AWS backend fix. Your best bet is to stay active on **AWS re:Post** and tag the **Amazon GuardDuty** team. Service teams monitor detailed technical reports like yours, and they may escalate it internally as a potential service-level bug.

* **Verification:** As a last resort, try toggling the EventBridge settings on the S3 bucket or slightly modifying the IAM Trust Policy. This sometimes forces the GuardDuty backend to re-validate the integration, but if that fails, only AWS Internal can fix the routing layer.

John H · Answer

Thank you for the detailed troubleshooting suggestions. We investigated all three scenarios:

1. EventBridge Suffix/Prefix Filtering

We verified the ObjectPrefixes on both plans:

Pre-prod: */uploads/
Dev: */*/uploads/, */*/attachments/, */*/tool-results/, */*/analysis/
Our smoke test paths match these patterns:

Pre-prod test: repro-{ts}/uploads/... → matches */uploads/
Dev test: 1000TEST/repro-{ts}/uploads/... → matches */*/uploads/
2. Storage Class & Object Size

Verified via head-object on test files from the April 26 timeframe:

Storage class: STANDARD (API returns null for default)
Object sizes: 55-69 bytes (non-zero)
Not Glacier, not empty.

3. Delegated Admin Conflict

Checked describe-organization-configuration on the delegated admin detector. All features show AutoEnable: NONE. Notably, S3 Malware Protection isn't listed in the org configuration output at all - only EBS Malware Protection appears.

The strongest evidence against customer-side issues:

The pre-prod plan (CreatedAt: 2026-04-26) is completely untouched since creation. Same ObjectPrefixes, same role, same bucket. It successfully scanned EICAR files on April 26 - we found objects with GuardDutyMalwareScanStatus: THREATS_FOUND tags from that date. Today, with zero configuration changes, it shows identical zero-scan behavior as dev.

This is a control case: if prefix filtering, storage class, or DA conflicts were the cause, pre-prod would have failed from day one - not worked and then silently stopped.

We agree the issue is in the routing layer given all three metrics are dead zero. Given the unchanged pre-prod configuration, this appears to be a backend synchronization issue between GuardDuty org-level state and standalone MalwareProtectionPlan resources that only AWS can diagnose.

Is there any way to escalate this without a paid support plan?

GuardDuty S3 Malware Protection plans show ACTIVE but never scan objects - health checks work, scans don't (be gentle, my first post).

Question

Environment

What We've Verified (All Correct)

The Diagnostic Fingerprint

Reproduction

CloudTrail Evidence

What We've Tried

Questions

Tags

Add your answer

Relevant content

Field	Value
Region	us-west-2
Organization ID	`o-abc1234def`
Delegated GD Admin	`111111111111`
Affected Account 1	`222222222222` (dev)
Affected Account 2	`333333333333` (preprod)
Plan ID (dev)	`aaaaaaaaaaaaaaaaaaaa`
Plan ID (preprod)	`bbbbbbbbbbbbbbbbbbbb`
Last successful scan	April 26, 2026 (2 EICAR test files tagged `THREATS_FOUND`)

Signal	Expected (Working)	Actual (Broken)
EventBridge `MatchedEvents`	>0	>0 ✓
EventBridge `Invocations`	= MatchedEvents	= MatchedEvents ✓
EventBridge `FailedInvocations`	0	0 ✓
CloudTrail `sts:AssumeRole`	Present	Present ✓ (every ~30 min)
CloudTrail `s3:GetObject` by scan session	Present	Zero ✗
CloudTrail `s3:PutObjectTagging` by scan session	Present	Zero ✗
`CompletedScanCount` metric	>0	Zero ✗
`FailedScanCount` metric	varies	Zero ✗
`SkippedScanCount` metric	varies	Zero ✗
S3 object `GuardDutyMalwareScanStatus` tag	Present	Never lands ✗