Hello,
The Fetching logs finished log infor only means the AWS wodle ran, doesn't necessarily always mean Security Hub findings were pulled and converted into alerts.
For Security Hub, based on the documentation, AWS modules are to read from an SQS queue using the Security Hub subscriber configuration, for example:
https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/security-hub.html<wodle name="aws-s3">
<disabled>no</disabled>
<interval>1h</interval>
<run_on_start>yes</run_on_start>
<subscriber type="security_hub">
<sqs_name>YOUR_SQS_QUEUE_NAME</sqs_name>
<aws_profile>YOUR_PROFILE</aws_profile>
</subscriber>
</wodle>
So first, please confirm you are using:
<subscriber type="security_hub">
and not a normal/custom S3 bucket configuration.
Next, enable debug temporarily on the node running the AWS wodle:
echo "wazuh_modules.debug=2" >> /var/ossec/etc/local_internal_options.conf
systemctl restart wazuh-manager
Then check one full run:
grep -iE "aws|security_hub|sqs|s3|ERROR|WARNING" /var/ossec/logs/ossec.log | tail -200
Also enable archives to know whether events are being fetched but not just producing alerts.
/var/ossec/etc/ossec.conf file.
<ossec_config>
<global>
----
<logall>yes</logall>
<logall_json>yes</logall_json>
Then restart the Wazuh-manager: systemctl restart wazuh-manager
Then check: cat /var/ossec/logs/archives/archives.json | grep "part of your log"
Verify that you have the logs, then disable archiving by setting the values to no.
The result should help isolate the issue.
No archives + no alerts means events are not reaching Wazuh.
Archives present + no alerts means decoding/rule matching issue.
Lastly, please check the AWS side: EventBridge/Firehose/S3/SQS. It could be that Security Hub findings exist in AWS, but no S3 object notification reaches the SQS queue that Wazuh is polling.
Please share the redacted <wodle name="aws-s3"> block and the debug output from one run.