Why Your AWS GuardDuty Data Isn't Showing Up in Microsoft Sentinel (And How to Fix It)

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:

1. GuardDuty writes findings to S3, encrypted with KMS


2. S3 Event Notification sends a message to SQS


3. The message in SQS was encrypted with KMS


4. Sentinel's OIDC role consumes the message from SQS (this works fine)


5. Sentinel tries to read the file contents — but they're encrypted


6. Sentinel can't call kms:Decrypt because it doesn't have permission


7. Sentinel silently fails and moves on


8. 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

1. Find your KMS key ARN — Go to GuardDuty → Settings → Findings export options. The KMS key ARN is displayed there.




2. 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.




3. 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).




4. 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:

• AWS GuardDuty Documentation


• Microsoft Sentinel AWS Connector