No log files AWS

[Alara Joel]

I keep getting this error 'No files were found in 'bucket-s3-gastec-siem/o-srvq2cpn6y/'. No logs will be processed". At first it was worst i was getting "No regions found for this Account: 'My account ID".

I think the problem is something to do with my path in ossec.conf. I have thoroughly checked everything from the AWS side, and it all seems great. 
 I have done a lot of troubleshooting, but I keep missing something. Im quite sure it's the path.

The User: 

My credential file is correct, my region is Stockholm eu-north-1, and i have that written in my config file. 
Mind you the AWS account has an organizational ID on it. Cloud trail logging is working fine on the AWS side, i can see the logs there nicely.
I have attached my wodle config section from ossec.conf, some pictures from my aws (policy and permissions)

Bucket: bucket-s3-gastec-siem
Trail-log-location according to aws dashboard: bucket-s3-gastec-siem/AWSLogs/o-srvq2cpn6y/337683XXXXXX

On opening that link, this is path i see inside; 337xx321xxxx/
inside that, there are threee folders : CloudTrail-Digest/ CloudTrail-Insight/ CloudTrail
In CloudTrail i see three regions (eu-north-1, eu-central-1, us-east-1. as far as i know we only really use 1 eu-north-1)
In them, i get months, days and then log files.
I changed the policy to include some new permissions when the default one didn't work.
My aws profile name for wazuh is called wazuh-aws.


What am I getting wrong? Thank you in advance for your help.

[Stuti Gupta]

Hi Alara,

The error you are seeing means Wazuh is able to access your S3 bucket, but it is not finding any files in the specific path you configured.

Right now Wazuh is checking:
s3://bucket-s3-gastec-siem/o-srvq2cpn6y/

We need to confirm whether there are actually CloudTrail logs in that exact location.

Please run this command from your server using the same AWS profile:

aws s3 ls s3://bucket-s3-gastec-siem/o-srvq2cpn6y/ --recursive --profile wazuh-aws

If this command returns no output, it means there are no files under that path, which explains the error. In that case, the <path> in your ossec.conf does not match the real location of your logs in the bucket.

If the command does return files, then the path is correct and we can look at other settings such as filters.

The key point is that Wazuh only reads from the exact prefix you configure, so the path must match the real S3 object structure exactly.

[Alara Joel]

Thanks, Gupta, that path didn't work, but now it did when I used this: bucket-s3-gastec-siem/AWSLogs/o-srvq2cpn6y/
It listed all the files. I will change it in the ossec.conf to see if it works now 

[Alara Joel]

Updated now, but still doesn't seem to be processing anything.

I get the results  in the second picture when I run this command: cat /var/ossec/logs/ossec.log | grep -i aws

On Tuesday, 5 May 2026 at 05:21:29 UTC Stuti Gupta wrote:

[Stuti Gupta]

Now the path issue looks resolved because Wazuh is no longer showing:
“No files were found”.

It is successfully starting the bucket analysis and finishing without path errors.

The next thing to verify is whether Wazuh is actually finding CloudTrail log files inside that prefix and whether they match the only_logs_after filter.

Please  run:

aws s3 ls s3://bucket-s3-gastec-siem/AWSLogs/o-srvq2cpn6y/ --recursive --profile wazuh-aws | tail

and confirm that the files are CloudTrail .json.gz log and the timestamps are newer than 2026-APR-27

Because you have:
<only_logs_after>2026-APR-27</only_logs_after>

[Alara Joel]

Thanks a lot, Gupta. Good day to you.
I ran the command : aws s3 ls s3://bucket-s3-gastec-siem/AWSLogs/o-srvq2cpn6y/ --recursive --profile wazuh-aws .
I took out the tails, and there are loads of logs there, but I realized they were from different regions. I don't know how the dev team has structured that. I see logs from ap-northeast-1, us-east-1, eu-north-1,  eu-central-1
Most of the other regions are CloudTrail digest logs, but eu-north-1, which I know we actually use, has almost all the CloudTrail logs. 

2026-05-05 23:56:52        731 AWSLogs/o-srvq2cpn6y/337683218317/CloudTrail-Digest/us-west-2/2026/05/05/337683218317_CloudTrail-Digest_us-west-2_gastec-platform-trail_eu-north-1_20260505T235203Z.json.gz

2026-04-27 11:08:18       1466 AWSLogs/o-srvq2cpn6y/337683218317/CloudTrail/eu-north-1/2026/04/27/337683218317_CloudTrail_eu-north-1_20260427T1105Z_V0J5C4b1K95uTsU6.json.gz

Am I getting the correct logs? What could the problem be now?

[Alara Joel]

Hello, good day everyone. 
Please some help here?

[Stuti Gupta]

Yes, those are the correct CloudTrail logs.

This file is the important one:

AWSLogs/o-srvq2cpn6y/337683218317/CloudTrail/eu-north-1/2026/04/27/...json.gz

The CloudTrail folder contains the real AWS event logs.

The CloudTrail-Digest files are only verification files

Your bucket path now looks correct because:

Wazuh is no longer showing "No files were found"

The AWS command is listing files correctly
The logs exist in the bucket

The next possible problem is this setting: <only_logs_after>2026-APR-27</only_logs_after>

Your sample log is also from 2026-04-27, so Wazuh may be skipping it because the date is the same.

Try changing it to an older date like:<only_logs_after>2026-APR-20</only_logs_after>

Then restart Wazuh: systemctl restart wazuh-manager

Check archives directly
On the manager server, check:
cat /var/ossec/logs/archives/archives.json | grep <keyword from the log>. 
Make sure log archiving is enabled in the Manager ossec.conf:
<logall>yes</logall>
<logall_json>yes</logall_json>

If this is not enabled > logs will not appear in archives even if received.
After enabling: systemctl restart wazuh-manager

Note: Enabling archives significantly increases disk usage and is not recommended for large-scale/production deployments unless you have adequate storage.
If Still Nothing Appears
Then check the logs again:

cat /var/ossec/logs/ossec.log | grep -i aws

[Alara Joel]

Hello Gupta thank you for your help.
I think at this point the best thing to do is to clear the whole thing and start again. 
Can I get a better walkthrough on how to set this up properly? I don't think i like the official guides much.
Thank you.

[Stuti Gupta]

Hi Alara,

I do not think you need to start from scratch anymore because the main issue already looks resolved.

At this point:

Wazuh is accessing the bucket correctly,
the AWS CLI command is listing the CloudTrail .json.gz files correctly and

Wazuh is no longer showing No files were found

So the integration itself now looks healthy.

The next thing I would recommend is temporarily removing or changing: <only_logs_after>2026-APR-27</only_logs_after>

because your sample logs are also from 2026-04-27, so Wazuh may be skipping them because of the date filter.

You can either temporarily remove it or try an older date like: <only_logs_after>2026-APR-20</only_logs_after>

Then restart the manager: systemctl restart wazuh-manager

If it still does not process the logs, then temporarily enable archives in the manager ossec.conf:

<logall>yes</logall>
<logall_json>yes</logall_json>

Then restart the manager again: systemctl restart wazuh-manager

After that, check whether the events are reaching: cat /var/ossec/logs/archives/archives.json | grep <keyword>

Please note that enabling archives can significantly increase disk usage and is generally not recommended for production environments unless adequate storage is available, so it is better to use it temporarily for troubleshooting only.

If the logs are present in the archives, we can create the rules so the alerts can trigger on the dashboard. But first, confirm if the logs are present or not.

If the archives are still empty after this, then check:

cat /var/ossec/logs/ossec.log | grep -i aws

for processing warnings or errors.

[Alara Joel]

Thanks a lot, Gupta. I had a series of night shifts, so I've not been able to work on this. 
I'd do as you have said and give you feedback.
How do I check for AWS logs in the archives?

We have an ELT/ETL server that talks to our AWS setup. 
So when I grep for AWS in archives, I see a lot of hits. But it's mostly from the ELT server. 
How do I specifically grep the logs that are coming straight from the CloudTrail S3 bucket?
Working on it all now, I'll get back to you soon.

[Alara Joel]

Also, it seems I am getting logs from more than one region, even though my main region is eu-north-1, I get logs from us-east-1 and eu-central-1.
How do we specify all these in the config file? or do i leave just one in the config file and add the multiple regions in the woodle in ossec.conf?

[Stuti Gupta]

Hi Alara,

For the archives check, instead of grepping a generic keyword like aws, try grepping for fields that are specific to CloudTrail events coming from the S3 integration. You can also grep for a specific AWS account ID, IAM user, event name, or resource name that you know exists inside the CloudTrail logs.

For example:

cat /var/ossec/logs/archives/archives.json | grep cloudtrail

or:

cat /var/ossec/logs/archives/archives.json | grep eventSource

Regarding the multiple AWS regions:

That is normal behavior for CloudTrail.

Even if your primary region is eu-north-1, CloudTrail can still contain events from other regions like us-east-1 or eu-central-1, depending on which AWS services are being used. Some AWS services are also global and commonly generate events in us-east-1. You do not need to create multiple Wazuh AWS blocks for each region if the logs are already centralized into the same S3 bucket.

Now, if the logs are in the archives but not in the dashboard. Then you need to create the rules for that. You can learn about rules from here https://documentation.wazuh.com/current/user-manual/ruleset/rules/index.html

In case you need help with rules, please share the related archives with me. (hide sensitive information).