Why Your AWS GuardDuty Data Isn't Showing Up in Microsoft...

The silent killer: KMS encryption blocking your SIEM integration with zero error logs

If you're integrating AWS GuardDuty with Microsoft Sentinel and your findings are mysteriously disappearing into the void, you're not alone. I spent hours debugging this issue, only to discover it was a KMS encryption permission problem — with absolutely no error logs to point me in the right direction.

Here's what happened and how I resolved the issue.

TL;DR

Problem: GuardDuty findings not appearing in Microsoft Sentinel, no error logs.

Cause: GuardDuty exports are KMS-encrypted, and Sentinel's IAM role lacks kms:Decrypt permission.

Solution: Add kms:Decrypt permission for your KMS key(s) to your Sentinel OIDC role.

The Setup

I was setting up Microsoft Sentinel to ingest AWS GuardDuty findings for centralized security monitoring. The architecture looked like this:

Everything seemed configured correctly:

GuardDuty export to S3 was enabled
S3 bucket permissions were set
S3 Event notification sends a message to SQS
Sentinel data connector was configured
SQS permissions were set allow s3 event publish the message
The SQS metric Number Of Messages Received show message was consumed
OIDC role for Sentinel had SQS consume permissions

But no data or table appeared in Sentinel. None. Zero. Zilch.

The Frustrating Part: No Errors

Here's what made this particularly painful to debug — there were no error logs anywhere.

I checked:

AzureDiagnostics table in Log Analytics — nothing
Sentinel data connector health — showed "connected"
SQS — Sentinel was consume the message fine
Request help from AWS Support confirm the message was consume specific role

Operation=ReceiveMessage
LPRemoteIpAddress=XX.XX.XXX.XX
AwsUserPrincipal=AROAXXXXXXXXXXXX:MicrosoftSentinel_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
MessageIds=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
AWSQueryStatusCode=200
RequestId=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
VisibilityTimeout=300
Queue.names=sentinel-soc-guardduty
ReceiveWaitTime=3000
RequesterUserARN=arn:aws:sts::XXXXXXXXXXXX:assumed-role/OIDC_aws-sentinel-oidc-role-guardduty/MicrosoftSentinel_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
AwsUserArn=arn:aws:sts::XXXXXXXXXXXX:assumed-role/OIDC_aws-sentinel-oidc-role-guardduty/MicrosoftSentinel_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
AwsAccessKeyId=ASIAXXXXXXXXXXXX
EndTime=Wed, 14 Jan 2026 10:28:43 UTC

The data was just silently disappearing. It's like Sentinel was reading the message, shrugging, and moving on without telling anyone.

The Root Cause: KMS Encryption

After way too much troubleshooting, I finally figured it out.

When you configure GuardDuty to export findings to S3, you can (and should) enable encryption. AWS lets you use a KMS key for this:

The problem? The GuardDuty finding files are encrypted with KMS, and Sentinel couldn't decrypt them.

Here's what was happening:

GuardDuty writes findings to S3, encrypted with KMS
S3 Event Notification sends a message to SQS
The message in SQS was encrypted with KMS
Sentinel's OIDC role consumes the message from SQS (this works fine)
Sentinel tries to read the file contents — but they're encrypted
Sentinel can't call kms:Decrypt because it doesn't have permission
Sentinel silently fails and moves on
No error is logged anywhere

The fact that there's no error logging for this scenario is... frustrating, to say the least.

The Fix

The solution is simple once you know the problem: add kms:Decrypt permission to your Sentinel OIDC role.

Add this statement to your Sentinel IAM role's policy:

{
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:YOUR-REGION:YOUR-ACCOUNT-ID:key/YOUR-KMS-KEY-ID"
],
"Effect": "Allow"
}

For example, my configuration needed:

{
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:ap-southeast-1:12345678:key/12345678",
],
"Effect": "Allow"
}

Step-by-Step

Find your KMS key ARN — Go to GuardDuty → Settings → Findings export options. The KMS key ARN is displayed there.
Find your Sentinel OIDC role — This is the role you created when setting up the AWS data connector in Sentinel. Mine was named OIDC_aws-sentinel-oidc-role-guardduty.
Update the IAM policy — Go to IAM → Roles → Your Sentinel role → Edit the attached policy → Add the kms:Decrypt permission for your KMS key(s).
Test the integration — Generate a sample finding in GuardDuty and wait 5-10 minutes. Check Sentinel with this KQL query:

AWSGuardDuty
| limit 10

Things to Remember

KMS key must be in the same region as your S3 bucket. AWS enforces this, so it shouldn't be an issue if your export is already working.

You might have multiple KMS keys. If you've changed keys or have different configurations, make sure all relevant keys are included in the policy.

The error won't show up in AzureDiagnostics. I wish I could tell you to look for a specific error, but there isn't one. If your GuardDuty data isn't appearing and everything else looks correct, check KMS permissions.

Related: