Check Point Harmony Endpoint Integration Fails on Log Retrieval (404) Despite Successful Manual API Tests

Elastic Stack Beats
,
1

Hello everyone,

I'm facing a persistent issue with the Check Point Harmony Endpoint Anti-Malware integration and would appreciate any insights the community might have.

The integration consistently fails to retrieve logs, and the agent logs show a 404 Not Found error during the log retrieval API call. The strange part is that I have manually replicated the entire API workflow using curl from the same server, and every step succeeds, including the final data retrieval.

Check Point Harmony Endpoint Integration Version: 1.0.0

The Problem in Detail: The checkpoint_harmony_endpoint.antimalware data stream fails to ingest data. The agent logs show the following error message, indicating a failure at the final /retrieve step: POST https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/retrieve: {\"success\":false,\"error\":{\"status\":404,\"name\":\"Not Found\",\"details\":[\"Requested resource could not be found or expired\"]}}

Troubleshooting Steps Performed: I have performed a full manual test of the Check Point API using curl, and every step was successful. This seems to rule out issues with credentials, permissions, network connectivity, firewalls, or proxies.

Here is the successful workflow I replicated:

1. Authentication: I successfully obtained a Bearer Token.

curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/auth/external' \ -H 'Content-Type: application/json' \ -d '{ "clientId": "xxxxx", "accessKey": "xxxxx" }'

Result: {"success":true, "data":{"token":"xxxxxx", "expires":"..."}}

2. Submit Log Query: Using the token, I successfully submitted a query for Anti-Malware logs and received a taskId.

curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <TOKEN_FROM_STEP_1>' \ -d '{"filter": "product:\"Anti-Malware\"", "timeframe": {"startTime": "...", "endTime": "..."}}'

Result: {"success":true, "data":{"taskId":"xxxxxxxxxxxxx"}}

3. Check Query Status: I polled the task status using the taskId and received a "Ready" state with a pageToken.

curl -X GET 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/<TASK_ID_FROM_STEP_2>' \ -H 'Authorization: Bearer <TOKEN_FROM_STEP_1>'

Result: {"success":true, "data":{"state":"Ready", "pageTokens":["xxxxxxx"]}}

4. Retrieve Log Data: Finally, I used the taskId and pageToken to retrieve the data, and I successfully received a JSON object containing the log records.

curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/retrieve' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <TOKEN_FROM_STEP_1>' \ -d '{"taskId": "<TASK_ID_FROM_STEP_2>", "pageToken": "<PAGETOKEN_FROM_STEP_3>"}'

Result: {"success":true,"data":{"records":[...]}}

Additional Steps Taken:

  • I have tried completely removing and re-adding the integration in the agent policy.
  • I have confirmed the correct Data Center URL is being used.

My Question: Given that all manual API calls work perfectly, why would the Elastic Agent integration fail at the final log retrieval step with a 404 Not Found?

Is this a known bug with this integration version, or are there any other internal configuration parameters (e.g., in the advanced YAML settings) that could be causing this discrepancy between the manual tests and the agent's execution?

Thank you in advance for any help or suggestions.

2

can you share the full configuration you've provided for the integration as well as a short snippet of the full log lines surrounding the error and including the error?

Are you using the exact same access_key and client_id across your manual test and the integration test?

you should also enable request tracing in the integration which will product an ndjson file on the endpoint with each request in it, it will almost certainly contain secrets but might reveal the difference between the request you're making and the request agent is making

it's not fun to look at but if you look at the CEL for the integration integrations/packages/checkpoint_harmony_endpoint/data_stream/antimalware/agent/stream/cel.yml.hbs at main · elastic/integrations · GitHub you can get an idea of what fields are packed into each request

3

Hello William,

Thank you for your prompt response and your helpful suggestions.

Answering your questions: I can confirm that the exact same clientId and accessKey are being used in both my manual curl tests and in the Fleet integration policy.

Regarding the configuration and logs, your suggestion to enable request tracing was the key. The trace logs provided such a clear picture of the issue—a logic flaw rather than a simple configuration error—that I believe they contain all the necessary information. The logs revealed a significant difference in behavior between the different data streams within the same integration.

Here is a side-by-side comparison of the trace logs from a failing stream (antimalware) and a working stream (Anti-Bot).

1. Failing Workflow: antimalware Data Stream

This log shows the agent authenticating successfully but then immediately skipping to the final /retrieve step with a stale taskId, which results in the 404 error.

Step 1: Authentication request.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:03.862-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/auth/external","http.request.method":"POST","http.request.body.content":"{\"accessKey\":\"[REDACTED_ACCESS_KEY]\",\"clientId\":\"[REDACTED_CLIENT_ID]\"}"}

Step 1: Authentication response - SUCCESS (200 OK).
{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.518-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"token\":\"[REDACTED_JWT_TOKEN]\",\"csrf\":\"[REDACTED_CSRF_TOKEN]\",\"expires\":\"...\"}}"}

Step 2: Data retrieval request (FAILURE POINT)
The agent skips the /logs_query step and incorrectly reuses a stale taskId.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.518-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query/retrieve","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"pageToken\":\"[REDACTED_PAGETOKEN]\",\"taskId\":\"e86c57dc-cffd-46b1-b5ab-7cff44855cec\"}"}

Step 2: Retrieval response - FAILURE (404 Not Found).
The API responds that the resource (the task) could not be found or has expired.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:05.223-0300","message":"HTTP response","http.response.status_code":404,"http.response.body.content":"{\"success\":false,\"error\":{\"status\":404,\"name\":\"Not Found\",\"details\":[\"Requested resource could not be found or expired\"]}}"}

2. Successful Workflow: Anti-Bot Data Stream

In contrast, this log from the Anti-Bot data stream (from the same agent and policy) shows the correct multi-step API workflow being executed perfectly.

Step 1: Submit a new log query for "Anti-Bot" product.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:03.802-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"filter\":\"product:\\\"Anti-Bot\\\"\",\"timeframe\":{\"startTime\":\"...\",\"endTime\":\"...\"}}"}

Step 1: Response - SUCCESS (200 OK), a fresh taskId is received.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.504-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"taskId\":\" **REDACTED_TASKID**\"}}"}

Step 2: Poll the status of the new taskId until "Ready".
{"log.level":"debug","@timestamp":"2025-08-04T15:03:06.477-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"state\":\"Ready\",\"pageTokens\":[\"[REDACTED_PAGETOKEN]\"]}}"}

Step 3: Retrieve the data using the fresh taskId and pageToken.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:06.477-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query/retrieve","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"pageToken\":\"[REDACTED_PAGETOKEN]\",\"taskId\":\"REDACTED_TASKID\"}"}**

Step 3: Response - SUCCESS (200 OK), log records are received.
{"log.level":"debug","@timestamp":"2025-08-04T15:03:07.685-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"records\":[{\"product\":\"Anti-Bot\",\"src\":\"[REDACTED_INTERNAL_IP]\",...}],\"recordsCount\":1,\"nextPageToken\":\"NULL\"}}"}

Analysis and Conclusion

The crucial finding from these logs is the difference in the API workflow. The Anti-Bot data stream works perfectly: it initiates a new query via POST /logs_query, receives a fresh taskId, polls the status of that task until it's "Ready", and then successfully retrieves the data with a POST /retrieve using the new task details.

In stark contrast, the antimalware data stream is flawed: after authenticating, it completely skips the query and polling steps. It immediately tries to call POST /retrieve using a static, stale taskId (e86c57dc-...) from a previous session. Because this task no longer exists on the Check Point server, the API correctly returns the 404 Not Found error.

Therefore, the evidence strongly suggests this is a state management bug specific to the antimalware data stream logic within the integration package (v1.0.0). Other data streams in the same integration are functioning correctly.

I hope this detailed analysis is useful for your team. Please let me know if there's anything else I can provide.

Best regards,

Gustavo