Troubleshooting Wazuh CTI
Use the following troubleshooting procedures to diagnose issues with Wazuh CTI content synchronization and Content Manager operations. Start by checking the synchronization state of the affected content category, then review the Content Manager configuration and Wazuh indexer logs for additional information. You can perform the Wazuh indexer API requests shown in this section by using curl or the Dev Tools console in the Wazuh dashboard.
CTI content is not updating
If CTI content is not updating, verify the connection to Wazuh CTI, the subscription status, and the synchronization state.
Perform the following checks:
Verify network connectivity. Ensure that the Wazuh indexer can connect to the Wazuh CTI service and that firewalls, proxies, or other network controls do not block the connection.
Check the subscription status. Verify that a valid Wazuh CTI subscription is registered if the requested operation or content requires authentication:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \ -X GET "https://<WAZUH_INDEXER_IP>:9200/_plugins/_content_manager/subscription"
Check the content category synchronization state. Run the following command:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \ "https://<WAZUH_INDEXER_IP>:9200/.wazuh-cti-consumers/_search?pretty"
Review the
status,local_offset, andremote_offsetfields for the affected content category.If
local_offsetequalsremote_offset, the content category is synchronized with the currently available content.If
local_offsetis lower thanremote_offset, newer content is available but has not yet been synchronized.If
local_offsetis0, the content category has not completed its initial synchronization.
Check the Wazuh indexer logs. Review
/var/log/wazuh-indexer/wazuh-indexer.logfor the Content Manager or CTI-related errors.
CTI synchronization fails
A CTI content synchronization enters the failed state when an unexpected error interrupts the synchronization process.
Check the content synchronization state to identify the affected content category:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
"https://<WAZUH_INDEXER_IP>:9200/.wazuh-cti-consumers/_search?pretty"
Then review the Wazuh indexer log:
$ grep -Ei "content.manager|Contentmanager|CatalogSync|consumer-sync|cti|CTIClient" \
/var/log/wazuh-indexer/wazuh-indexer.log
To search specifically for related errors, run:
$ grep -Ei "ERROR.*content.manager" \
/var/log/wazuh-indexer/wazuh-indexer.log
Common causes include connectivity problems, invalid or expired subscription credentials, unavailable CTI services, and errors while processing or storing synchronized content.
Content Manager retries a failed scheduled synchronization during the next synchronization cycle. Resolve the underlying issue and verify that the content synchronization state returns to the ready state after a subsequent synchronization.
Manual synchronization fails
If an on-demand synchronization request fails, use the returned status code to identify the cause.
Status |
Cause |
Action |
|---|---|---|
|
A content synchronization operation is already running. |
Wait for the current synchronization to complete before trying again. |
|
On-demand synchronization is disabled. |
Enable
|
You can verify that on-demand synchronization is enabled in /etc/wazuh-indexer/opensearch.yml:
plugins.content_manager.catalog.update_on_demand: true
After resolving the issue, trigger synchronization again:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
-X POST "https://<WAZUH_INDEXER_IP>:9200/_plugins/_content_manager/update"
A successful request returns a 202 status, indicating that the synchronization request has been accepted for processing.
Verify synchronized content
You can verify that the Content Manager has populated the expected content by checking the document count in the relevant content indices.
For example, check the number of synchronized rules:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
"https://<WAZUH_INDEXER_IP>:9200/wazuh-threatintel-rules/_count?pretty"
{
"count": 268,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
}
}
You can perform the same check for the applicable CTI content indices:
wazuh-threatintel-ruleswazuh-threatintel-decoderswazuh-threatintel-integrationswazuh-threatintel-kvdbswazuh-threatintel-policieswazuh-threatintel-enrichments
A non-zero document count confirms that the index contains content, but it does not by itself confirm that the content is current.
Content Manager jobs do not start
Content Manager uses scheduled jobs to perform periodic CTI synchronization and Wazuh version update checks. These jobs require the .wazuh-content-manager-jobs index to reach the required health state before they can register.
Check the Wazuh indexer cluster health:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
"https://<WAZUH_INDEXER_IP>:9200/_cluster/health?pretty"
You can also inspect the Content Manager job metadata:
$ curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
"https://<WAZUH_INDEXER_IP>:9200/.wazuh-content-manager-jobs/_search?pretty"
If a job cannot register during startup, the Content Manager retries the registration up to three times. The retries use increasing delays of 15, 30, and 45 seconds. If all attempts fail, the Content Manager records an error in the Wazuh indexer log and does not attempt to register the job again until the next Wazuh indexer restart.
Search the logs for job scheduling errors:
$ grep -Ei "CatalogSyncJob|scheduling|content.manager" \
/var/log/wazuh-indexer/wazuh-indexer.log
If the .wazuh-content-manager-jobs index is unavailable or unhealthy, investigate the Wazuh indexer cluster health and shard allocation before restarting the affected Wazuh indexer node.