wazuh alert id

88 views
Skip to first unread message

никита какдела

unread,
May 27, 2026, 8:51:40 AM (11 days ago) May 27
to Wazuh | Mailing List
{"version": 1, "origin": {"name": "worker03-node", "module": "wazuh-execd"}, "command": "add", "parameters": {"extra_args": [], "alert": {"timestamp": "2026-05-27T10:51:12.629+0000", "rule": {"level": 10, "description": "Вход администратора по RDP", "id": "100052", "mitre": {"id": ["T1021.001", "T1078.002"], "tactic": ["Lateral Movement", "Defense Evasion", "Persistence", "Privilege Escalation", "Initial Access"], "technique": ["Remote Desktop Protocol", "Domain Accounts"]}, "firedtimes": 4, "mail": false, "groups": ["InfoSec", "infosec_alerts", "authentication_success"]}, "agent": {"id": "181", "name": "test1-host", "ip": "10.10.10.10"}, "manager": {"name": "wzhcl3-msk01"}, "id": "1779879072.7049200586", "cluster": {"name": "wazuh", "node": "worker03-node"}, "full_log": "{\"win\":{\"system\":{\"providerName\":\"Microsoft-Windows-Security-Auditing\",\"providerGuid\":\"{54849625-5478-4994-a5ba-3e3b0328c30d}\",\"eventID\":\"4624\",\"version\":\"2\",\"level\":\"0\",\"task\":\"12544\",\"opcode\":\"0\",\"keywords\":\"0x8020000000000000\",\"systemTime\":\"2026-05-27T10:51:12.5106039Z\",\"eventRecordID\":\"958608\",\"processID\":\"968\",\"threadID\":\"760\",\"channel\":\"Security\",\"computer\":\"tsa1v-msk01.ovp.ru\",\"severityValue\":\"AUDIT_SUCCESS\",\"message\":\"\\\"Вход в учетную запись выполнен успешно.\\r\\n\\r\\nСубъект:\\r\\n\\tИД безопасности:\\t\\tS-1-5-18\\r\\n\\tИмя учетной записи:\\t\\ttest-host1$\\r\\n\\tДомен учетной записи:\\t\\tOVP\\r\\n\\tИД входа:\\t\\t0x3E7\\r\\n\\r\\nСведения о входе:\\r\\n\\tТип входа:\\t\\t10\\r\\n\\tОграниченный режим администрирования:\\tНет\\r\\n\\tВиртуальная учетная запись:\\t\\tНет\\r\\n\\tРасширенный маркер:\\t\\tНет\\r\\n\\r\\nУровень олицетворения:\\t\\tОлицетворение\\r\\n\\r\\nНовый вход:\\r\\n\\tИД безопасности:\\t\\tS-1-5-21-1574252229-270539701-1819828000-35576\\r\\n\\tИмя учетной записи:\\t\\tnshelamov_a\\r\\n\\tДомен учетной записи:\\t\\tOVP\\r\\n\\tИД входа:\\t\\t0xDCF35F8\\r\\n\\tСвязанный ИД входа:\\t\\t0xDCF34DC\\r\\n\\tСетевое имя учетной записи:\\t-\\r\\n\\tСетевой домен учетной записи:\\t-\\r\\n\\tGUID входа:\\t\\t{00000000-0000-0000-0000-000000000000}\\r\\n\\r\\nСведения о процессе:\\r\\n\\tИД процесса:\\t\\t0x980\\r\\n\\tИмя процесса:\\t\\tC:\\\\Windows\\\\System32\\\\svchost.exe\\r\\n\\r\\nСведения о сети:\\r\\n\\tИмя рабочей станции:\\tTSA1V-MSK01\\r\\n\\tСетевой адрес источника:\\t10.250.22.10\\r\\n\\tПорт источника:\\t\\t0\\r\\n\\r\\nПодробные сведения о проверке подлинности:\\r\\n\\tПроцесс входа:\\t\\tUser32 \\r\\n\\tПакет проверки подлинности:\\tNegotiate\\r\\n\\tПромежуточные службы:\\t-\\r\\n\\tИмя пакета (только NTLM):\\t-\\r\\n\\tДлина ключа:\\t\\t0\\r\\n\\r\\nДанное событие возникает при создании сеанса входа. Оно создается на компьютере, к которому был установлен доступ.\\r\\n\\r\\nПоля \\\"Субъект\\\" указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например служба \\\"Сервер\\\", или локальный процесс, такой как Winlogon.exe или Services.exe.\\r\\n\\r\\nВ поле \\\"Тип входа\\\" указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).\\r\\n\\r\\nПоля \\\"Новый вход\\\" указывают на учетную запись, для которой создан новый сеанс входа, то есть на учетную запись, в которую выполнен вход.\\r\\n\\r\\nВ полях, которые относятся к сети, указан источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.\\r\\n\\r\\nПоле \\\"Уровень олицетворения\\\" задает допустимую степень олицетворения для процессов в данном сеансе входа.\\r\\n\\r\\nПоля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.\\r\\n\\t- GUID входа — это уникальный идентификатор, который позволяет сопоставить данное событие с событием KDC.\\r\\n\\t- В поле \\\"Промежуточные службы\\\" указано, какие промежуточные службы участвовали в данном запросе на вход.\\r\\n\\t- Поле \\\"Имя пакета\\\" указывает на подпротокол, использованный с протоколами NTLM.\\r\\n\\t- В поле \\\"Длина ключа\\\" указывается длина созданного ключа сеанса. Это поле может иметь значение \\\"0\\\", если ключ сеанса не запрашивался.\\\"\"},\"eventdata\":{\"subjectUserSid\":\"S-1-5-18\",\"subjectUserName\":\"TSA1V-MSK01$\",\"subjectDomainName\":\"OVP\",\"subjectLogonId\":\"0x3e7\",\"targetUserSid\":\"1232121\",\"targetUserName\":\"nshelamov_a\",\"targetDomainName\":\"OVP\",\"targetLogonId\":\"0xdcf35f8\",\"logonType\":\"10\",\"logonProcessName\":\"User32\",\"authenticationPackageName\":\"Negotiate\",\"workstationName\":\"test-host1\",\"logonGuid\":\"{00000000-0000-0000-0000-000000000000}\",\"keyLength\":\"0\",\"processId\":\"0x980\",\"processName\":\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\svchost.exe\",\"ipAddress\":\"123.123.123.123\",\"ipPort\":\"0\",\"impersonationLevel\":\"%%1833\",\"restrictedAdminMode\":\"%%1843\",\"virtualAccount\":\"%%1843\",\"targetLinkedLogonId\":\"0xdcf34dc\",\"elevatedToken\":\"%%1843\"}}}", "decoder": {"name": "windows_eventchannel"}, "data": {"win": {"system": {"providerName": "Microsoft-Windows-Security-Auditing", "providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}", "eventID": "4624", "version": "2", "level": "0", "task": "12544", "opcode": "0", "keywords": "0x8020000000000000", "systemTime": "2026-05-27T10:51:12.5106039Z", "eventRecordID": "958608", "processID": "968", "threadID": "760", "channel": "Security", "computer": "test-host1", "severityValue": "AUDIT_SUCCESS",  "eventdata": {"subjectUserSid": "S-1-5-18", "subjectUserName": "test-host1$", "subjectDomainName": "OVP", "subjectLogonId": "0x3e7", "targetUserSid": "111", "targetUserName": "user", "targetDomainName": "OVP", "targetLogonId": "0xdcf35f8", "logonType": "10", "logonProcessName": "User32", "authenticationPackageName": "Negotiate", "workstationName": "testhost1", "logonGuid": "{00000000-0000-0000-0000-000000000000}", "keyLength": "0", "processId": "0x980", "processName": "C:\\\\Windows\\\\System32\\\\svchost.exe", "ipAddress": "10.250.22.10", "ipPort": "0", "impersonationLevel": "%%1833", "restrictedAdminMode": "%%1843", "virtualAccount": "%%1843", "targetLinkedLogonId": "0xdcf34dc", "elevatedToken": "%%1843"}}}, "location": "EventChannel"}, "program": "active-response/bin/notify_universal.py"}}



{ "_index": "wazuh-alerts-4.x-2026.05.27", "_id": "ebwPaZ4BibM6I6cPWVZN", "_version": 1, "_score": null, "_source": { "cluster": { "node": "worker03-node", "name": "wazuh" }, "input": { "type": "log" }, "agent": { "ip": "10.10.10.10.", "name": "testhost1", "id": "181" }, "manager": { "name": "wzhcl3-msk01" }, "data": { "win": { "eventdata": { "subjectLogonId": "0xdcf34dc", "subjectUserSid": "S-1-5-21-1574252229-270539701-1819828000-35576", "subjectDomainName": "work", "privilegeList": "SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege", "subjectUserName": "user" }, "system": { "eventID": "4672", "keywords": "0x8020000000000000", "providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}", "level": "0", "channel": "Security", "opcode": "0", "message": "\"Новому сеансу входа назначены специальные привилегии.\r\n\r\nСубъект:\r\n\tИД безопасности:\t\tS-1-5-21-1574252229-270539701-1819828000-35576\r\n\tИмя учетной записи:\t\tnshelamov_a\r\n\tДомен учетной записи:\t\tOVP\r\n\tКод входа:\t\t0xDCF34DC\r\n\r\nПривилегии:\t\tSeSecurityPrivilege\r\n\t\t\tSeTakeOwnershipPrivilege\r\n\t\t\tSeLoadDriverPrivilege\r\n\t\t\tSeBackupPrivilege\r\n\t\t\tSeRestorePrivilege\r\n\t\t\tSeDebugPrivilege\r\n\t\t\tSeSystemEnvironmentPrivilege\r\n\t\t\tSeImpersonatePrivilege\r\n\t\t\tSeDelegateSessionUserImpersonatePrivilege\"", "version": "0", "systemTime": "2026-05-27T10:51:12.5106459Z", "eventRecordID": "958610", "threadID": "760", "computer": "test-host1.ovp.ru", "task": "12548", "processID": "968", "severityValue": "AUDIT_SUCCESS", "providerName": "Microsoft-Windows-Security-Auditing" } } }, "rule": { "firedtimes": 3245, "mail": false, "level": 3, "description": "Special privileges assigned to new logon.", "groups": [ "windows", " WEF" ], "mitre": { "technique": [ "Domain Policy Modification" ], "id": [ "T1484" ], "tactic": [ "Defense Evasion", "Privilege Escalation" ] }, "id": "67028" }, "location": "EventChannel", "decoder": { "name": "windows_eventchannel" }, "id": "1779879072.7049200586", "timestamp": "2026-05-27T10:51:12.633+0000" }, "fields": { "timestamp": [ "2026-05-27T10:51:12.633Z" ] }, "highlight": { "id": [ "@opensearch-dashboar...@1779879072.7049200586@/opensearch-dashboards-highlighted-field@" ] }, "sort": [ 1779879072633 ] } One event from active - response and one from discover. I ran into this problem when my active-response is triggered on my rules.groups, I get the event in its raw form (attached from above, first). There is a document id there, then I make a request to the indexer using this id to get the _id (to build a link to the document). and I noticed that the link I get leads to a completely different document, then I decided to compare the ids. and I found that they are the same, and the document that came to me in active-response has a different id, not the one that was in its raw form. What kind of nonsense is this? Why does it work this way? Can you explain?  

Eli Josue Rodriguez

unread,
May 27, 2026, 9:52:20 AM (11 days ago) May 27
to Wazuh | Mailing List
Hi,

The behavior is expected and is related to the difference between the Wazuh alert id field and the OpenSearch document _id.

The id value received in Active Response (for example 1779879072.7049200586) is the internal Wazuh alert identifier generated by the manager. This is the same value stored in the document field id, but it is NOT the same as the OpenSearch _id.

The OpenSearch _id (for example ebwPaZ4BibM6I6cPWVZN) is generated later by the indexer during document ingestion and indexing. At the moment Active Response is executed, this _id does not exist yet.

Because of this, searching directly by _id using the Wazuh alert id will not return the expected document.

The correct approach is:

  1. Use the alert id received by Active Response.

  2. Search the index using:

    { "query": { "term": { "id.keyword": "1779879072.7049200586" } } }
  3. Retrieve the real OpenSearch _id from the search result.

  4. Build the dashboard link using that _id.

Additionally, in the provided example, the Active Response event and the Discover event are not the same alert:

  • Active Response was triggered by Event ID 4624 with custom rule 100052

  • Discover shows Event ID 4672 with rule 67028

These Windows events are closely related and may share the same Wazuh alert id due to event correlation and processing timing.

https://documentation.wazuh.com/current/user-manual/capabilities/active-response/index.html

никита какдела

unread,
May 28, 2026, 5:38:26 AM (10 days ago) May 28
to Wazuh | Mailing List

Dear friend, you have not fully understood. I don't mean the _id field. I know perfectly well that it appears after indexing the document. Now I'm telling you about the "id" field that I get after active-response is triggered. In the document that I received after the active-response, I have the id 1779879072.7049200586. Next, logically, I need to get the _id from this id (to build a link using _index + _id). And what do I see? I see a completely different document, a different event, a different rule, but the same id (1779879072.7049200586). And in fact, the first event that worked, for some reason it changes its id (not _id). I specially attached two events from above that have the same id, but the events are actually different. How is this possible?
среда, 27 мая 2026 г. в 16:52:20 UTC+3, Eli Josue Rodriguez:

никита какдела

unread,
May 28, 2026, 5:38:32 AM (10 days ago) May 28
to Wazuh | Mailing List
Alert by active-response: (id  1779879072.7049200586


{"version": 1, "origin": {"name": "worker03-node", "module": "wazuh-execd"}, "command": "add", "parameters": {"extra_args": [], "alert": {"timestamp": "2026-05-27T10:51:12.629+0000", "rule": {"level": 10, "description": "Вход администратора по RDP", "id": "100052", "mitre": {"id": ["T1021.001", "T1078.002"], "tactic": ["Lateral Movement", "Defense Evasion", "Persistence", "Privilege Escalation", "Initial Access"], "technique": ["Remote Desktop Protocol", "Domain Accounts"]}, "firedtimes": 4, "mail": false, "groups": ["InfoSec", "infosec_alerts", "authentication_success"]}, "agent": {"id": "181", "name": "test1-host", "ip": "10.10.10.10"}, "manager": {"name": "wzhcl3-msk01"}, "id": "1779879072.7049200586", "cluster": {"name": "wazuh", "node": "worker03-node"}, "full_log": "{\"win\":{\"system\":{\"providerName\":\"Microsoft-Windows-Security-Auditing\",\"providerGuid\":\"{54849625-5478-4994-a5ba-3e3b0328c30d}\",\"eventID\":\"4624\",\"version\":\"2\",\"level\":\"0\",\"task\":\"12544\",\"opcode\":\"0\",\"keywords\":\"0x8020000000000000\",\"systemTime\":\"2026-05-27T10:51:12.5106039Z\",\"eventRecordID\":\"958608\",\"processID\":\"968\",\"threadID\":\"760\",\"channel\":\"Security\",\"computer\":\"tsa1v-msk01.ovp.ru\",\"severityValue\":\"AUDIT_SUCCESS\",\"message\":\"\\\"Вход в учетную запись выполнен успешно.\\r\\n\\r\\nСубъект:\\r\\n\\tИД безопасности:\\t\\tS-1-5-18\\r\\n\\tИмя учетной записи:\\t\\ttest-host1$\\r\\n\\tДомен учетной записи:\\t\\tOVP\\r\\n\\tИД входа:\\t\\t0x3E7\\r\\n\\r\\nСведения о входе:\\r\\n\\tТип входа:\\t\\t10\\r\\n\\tОграниченный режим администрирования:\\tНет\\r\\n\\tВиртуальная учетная запись:\\t\\tНет\\r\\n\\tРасширенный маркер:\\t\\tНет\\r\\n\\r\\nУровень олицетворения:\\t\\tОлицетворение\\r\\n\\r\\nНовый вход:\\r\\n\\tИД безопасности:\\t\\tS-1-5-21-1574252229-270539701-1819828000-35576\\r\\n\\tИмя учетной записи:\\t\\tnshelamov_a\\r\\n\\tДомен учетной записи:\\t\\tOVP\\r\\n\\tИД входа:\\t\\t0xDCF35F8\\r\\n\\tСвязанный ИД входа:\\t\\t0xDCF34DC\\r\\n\\tСетевое имя учетной записи:\\t-\\r\\n\\tСетевой домен учетной записи:\\t-\\r\\n\\tGUID входа:\\t\\t{00000000-0000-0000-0000-000000000000}\\r\\n\\r\\nСведения о процессе:\\r\\n\\tИД процесса:\\t\\t0x980\\r\\n\\tИмя процесса:\\t\\tC:\\\\Windows\\\\System32\\\\svchost.exe\\r\\n\\r\\nСведения о сети:\\r\\n\\tИмя рабочей станции:\\tTSA1V-MSK01\\r\\n\\tСетевой адрес источника:\\t10.250.22.10\\r\\n\\tПорт источника:\\t\\t0\\r\\n\\r\\nПодробные сведения о проверке подлинности:\\r\\n\\tПроцесс входа:\\t\\tUser32 \\r\\n\\tПакет проверки подлинности:\\tNegotiate\\r\\n\\tПромежуточные службы:\\t-\\r\\n\\tИмя пакета (только NTLM):\\t-\\r\\n\\tДлина ключа:\\t\\t0\\r\\n\\r\\nДанное событие возникает при создании сеанса входа. Оно создается на компьютере, к которому был установлен доступ.\\r\\n\\r\\nПоля \\\"Субъект\\\" указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например служба \\\"Сервер\\\", или локальный процесс, такой как Winlogon.exe или Services.exe.\\r\\n\\r\\nВ поле \\\"Тип входа\\\" указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).\\r\\n\\r\\nПоля \\\"Новый вход\\\" указывают на учетную запись, для которой создан новый сеанс входа, то есть на учетную запись, в которую выполнен вход.\\r\\n\\r\\nВ полях, которые относятся к сети, указан источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.\\r\\n\\r\\nПоле \\\"Уровень олицетворения\\\" задает допустимую степень олицетворения для процессов в данном сеансе входа.\\r\\n\\r\\nПоля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.\\r\\n\\t- GUID входа — это уникальный идентификатор, который позволяет сопоставить данное событие с событием KDC.\\r\\n\\t- В поле \\\"Промежуточные службы\\\" указано, какие промежуточные службы участвовали в данном запросе на вход.\\r\\n\\t- Поле \\\"Имя пакета\\\" указывает на подпротокол, использованный с протоколами NTLM.\\r\\n\\t- В поле \\\"Длина ключа\\\" указывается длина созданного ключа сеанса. Это поле может иметь значение \\\"0\\\", если ключ сеанса не запрашивался.\\\"\"},\"eventdata\":{\"subjectUserSid\":\"S-1-5-18\",\"subjectUserName\":\"TSA1V-MSK01$\",\"subjectDomainName\":\"OVP\",\"subjectLogonId\":\"0x3e7\",\"targetUserSid\":\"1232121\",\"targetUserName\":\"nshelamov_a\",\"targetDomainName\":\"OVP\",\"targetLogonId\":\"0xdcf35f8\",\"logonType\":\"10\",\"logonProcessName\":\"User32\",\"authenticationPackageName\":\"Negotiate\",\"workstationName\":\"test-host1\",\"logonGuid\":\"{00000000-0000-0000-0000-000000000000}\",\"keyLength\":\"0\",\"processId\":\"0x980\",\"processName\":\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\svchost.exe\",\"ipAddress\":\"123.123.123.123\",\"ipPort\":\"0\",\"impersonationLevel\":\"%%1833\",\"restrictedAdminMode\":\"%%1843\",\"virtualAccount\":\"%%1843\",\"targetLinkedLogonId\":\"0xdcf34dc\",\"elevatedToken\":\"%%1843\"}}}", "decoder": {"name": "windows_eventchannel"}, "data": {"win": {"system": {"providerName": "Microsoft-Windows-Security-Auditing", "providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}", "eventID": "4624", "version": "2", "level": "0", "task": "12544", "opcode": "0", "keywords": "0x8020000000000000", "systemTime": "2026-05-27T10:51:12.5106039Z", "eventRecordID": "958608", "processID": "968", "threadID": "760", "channel": "Security", "computer": "test-host1", "severityValue": "AUDIT_SUCCESS",  "eventdata": {"subjectUserSid": "S-1-5-18", "subjectUserName": "test-host1$", "subjectDomainName": "OVP", "subjectLogonId": "0x3e7", "targetUserSid": "111", "targetUserName": "user", "targetDomainName": "OVP", "targetLogonId": "0xdcf35f8", "logonType": "10", "logonProcessName": "User32", "authenticationPackageName": "Negotiate", "workstationName": "testhost1", "logonGuid": "{00000000-0000-0000-0000-000000000000}", "keyLength": "0", "processId": "0x980", "processName": "C:\\\\Windows\\\\System32\\\\svchost.exe", "ipAddress": "10.250.22.10", "ipPort": "0", "impersonationLevel": "%%1833", "restrictedAdminMode": "%%1843", "virtualAccount": "%%1843", "targetLinkedLogonId": "0xdcf34dc", "elevatedToken": "%%1843"}}}, "location": "EventChannel"}, "program": "active-response/bin/notify_universal.py"}}


Search the index using: (id.keyword 1779879072.7049200586)

user@wazuh# curl -k -u user:user   "https://10.10.10.10/wazuh-alerts-4.x-2026.05.27/_search?pretty"   -H "Content-Type: application/json"   -d '{"size":5,"_source":["id","rule.id","rule.description","agent.name"],"query":{"term":{"id.keyword":"1779879072.7049200586"}}}'
{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

Search the index using: (id 1779879072.7049200586)

user@wazuh# curl -k -u user:user   "https://10.10.10.10/wazuh-alerts-4.x-2026.05.27/_search?pretty"   -H "Content-Type: application/json"   -d '{"size":5,"_source":["id","rule.id","rule.description","agent.name"],"query":{"term":{"id":"1779879072.7049200586"}}}'
{
  "took" : 2,
  "timed_out" : false,
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 14.741758,
    "hits" : [
      {

        "_index" : "wazuh-alerts-4.x-2026.05.27",
        "_id" : "ebwPaZ4BibM6I6cPWVZN",
        "_score" : 14.741758,
        "_source" : {
          "agent" : {
            "name" : "host-1"
          },
          "rule" : {

            "description" : "Special privileges assigned to new logon.",
            "id" : "67028"
          },
          "id" : "1779879072.7049200586"
        }
      }
    ]
  }
}


Is this a bug? Or what am I doing wrong?
среда, 27 мая 2026 г. в 16:52:20 UTC+3, Eli Josue Rodriguez:
Hi,

никита какдела

unread,
May 29, 2026, 3:48:57 AM (9 days ago) May 29
to Wazuh | Mailing List
Sorry team?
четверг, 28 мая 2026 г. в 12:38:32 UTC+3, никита какдела:

никита какдела

unread,
Jun 1, 2026, 2:09:27 AM (6 days ago) Jun 1
to Wazuh | Mailing List
So can you help me?

пятница, 29 мая 2026 г. в 10:48:57 UTC+3, никита какдела:

Eli Josue Rodriguez

unread,
Jun 2, 2026, 9:03:10 AM (5 days ago) Jun 2
to Wazuh | Mailing List
Hi,

Apologies for the delayed response. I was OOO.

Thank you for the detailed examples and for clarifying the issue. I understand now that the concern is not related to the OpenSearch `_id`, but rather that the same Wazuh alert `id` appears to be associated with different events, and that the alert received by Active Response does not match the document returned when searching the index using that same `id`.

I've reviewed the data you shared, and I'd like to discuss this internally with our team to better understand whether this is expected behavior,

I'll get back to you as soon as I have more information.

Eli Josue Rodriguez

unread,
Jun 3, 2026, 12:13:04 PM (4 days ago) Jun 3
to Wazuh | Mailing List
Hi,

Thank you for your patience, and apologies for the delay in getting back to you.

I discussed the behavior internally with the team and we also performed additional checks. So far, we have not been able to reproduce the behavior where different alerts are generated with the same alert ID.

Based on our review, alert IDs are expected to be unique per worker. While there is a very small theoretical possibility of collisions in clustered environments, we were not able to observe the behavior described in your example during our tests.

At this point, we recommend validating the alert directly from the source files on the manager/workers, since Active Response receives its input from the alert files before the data is indexed. This will help determine whether the same alert ID is actually being generated multiple times or whether the discrepancy is occurring elsewhere in the workflow.

For example, you can search for the alert ID across the alert files:

grep "1779879072.7049200586" /var/ossec/logs/alerts/alerts.json*

and verify whether multiple alerts are present with that same ID.

Additionally, since the Active Response output shown comes from a custom script, it would also be worth validating how the script captures and stores the input received from Wazuh.

Based on the information currently available and our internal testing, we have not identified an issue in Wazuh that would explain the observed behavior.
Reply all
Reply to author
Forward
0 new messages