Wazuh get's flooded with Authentification failure messages

103 views

Skip to first unread message

Andrehens Chicfici

unread,

Oct 8, 2024, 6:18:06 AM10/8/24

to Wazuh | Mailing List

Hey,

I managed to get my complete environment into my wazuh instance.

A few times a day my message queue locks up with the error message:

WARNING: Target 'agent' message queue is full (1024). Log lines may be lost.

Now that I am able to hunt inconsistences with my dashboard I can verify that the error occurs when I get around 440.000 notifications per hour. Around 36.000 notifications are authentification failures. 3.500 notifications are authentication successes.

Going further down the rabbit hole I can see the same windows event triggering from different servers:

{
"_index": "wazuh-alerts-4.x-2024.10.08",
"_id": "YleHa5IBYEKCAcBzMaq3",
"_score": 1,
"_source": {
"agent": {
"ip": "XXX.XXX.XXX.XXX",
"name": "DC-X",
"id": "089"
},
"manager": {
"name": "wazuh"
},
"data": {
"win": {
"eventdata": {
"subjectLogonId": "0x0",
"ipAddress": "XXX.XXX.XXX.XXX",
"authenticationPackageName": "NTLM",
"workstationName": "WORKSTATION",
"subStatus": "0xc000006e",
"logonProcessName": "NtLmSsp",
"targetUserName": "WORKSTATION",
"keyLength": "0",
"subjectUserSid": "S-1-0-0",
"processId": "0x0",
"ipPort": "16822",
"failureReason": "%%2313",
"targetDomainName": "DOMAIN",
"targetUserSid": "S-1-0-0",
"logonType": "3",
"status": "0xc000006e"
},
"system": {
"eventID": "4625",
"keywords": "0x8010000000000000",
"providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
"level": "0",
"channel": "Security",
"opcode": "0",
"message": "\"Fehler beim Anmelden eines Kontos.\r\n\r\nAntragsteller:\r\n\tSicherheits-ID:\t\tS-1-0-0\r\n\tKontoname:\t\t-\r\n\tKontodomäne:\t\t-\r\n\tAnmelde-ID:\t\t0x0\r\n\r\nAnmeldetyp:\t\t\t3\r\n\r\nKonto, für das die Anmeldung fehlgeschlagen ist:\r\n\tSicherheits-ID:\t\tS-1-0-0\r\n\tKontoname:\t\tWORKSTATION\r\n\tKontodomäne:\t\tDOMAIN\r\n\r\nFehlerinformationen:\r\n\tFehlerursache:\t\tUnbekannter Benutzername oder ungültiges Kennwort.\r\n\tStatus:\t\t\t0xC000006E\r\n\tUnterstatus::\t\t0xC000006E\r\n\r\nProzessinformationen:\r\n\tAufrufprozess-ID:\t0x0\r\n\tAufrufprozessname:\t-\r\n\r\nNetzwerkinformationen:\r\n\tArbeitsstationsname:\tWORKSTATION\r\n\tQuellnetzwerkadresse:\tXXX.XXX.XXX.XXX\r\n\tQuellport:\t\t16822\r\n\r\nDetaillierte Authentifizierungsinformationen:\r\n\tAnmeldeprozess:\t\tNtLmSsp \r\n\tAuthentifizierungspaket:\tNTLM\r\n\tÜbertragene Dienste:\t-\r\n\tPaketname (nur NTLM):\t-\r\n\tSchlüssellänge:\t\t0\r\n\r\nDieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.\r\n\r\nDie Antragstellerfelder geben das Konto auf dem localen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein localer Prozess wie \"Winlogon.exe\" oder \"Services.exe\".\r\n\r\nDas Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).\r\n\r\nDie Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.\r\n\r\nDie Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.\r\n\r\nDie Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.\r\n\t- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.\r\n\t- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.\r\n\t- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.\"",
"version": "0",
"systemTime": "2024-10-08T09:47:53.5185767Z",
"eventRecordID": "44813233",
"threadID": "2076",
"computer": "DC-X.DOMAIN.local",
"task": "12544",
"processID": "672",
"severityValue": "AUDIT_FAILURE",
"providerName": "Microsoft-Windows-Security-Auditing"
}
}
},
"rule": {
"mail": false,
"level": 5,
"pci_dss": [
"10.2.4",
"10.2.5"
],
"hipaa": [
"164.312.b"
],
"tsc": [
"CC6.1",
"CC6.8",
"CC7.2",
"CC7.3"
],
"description": "Logon Failure - Unknown user or bad password",
"groups": [
"windows",
"windows_security",
"authentication_failed"
],
"nist_800_53": [
"AU.14",
"AC.7"
],
"gdpr": [
"IV_35.7.d",
"IV_32.2"
],
"firedtimes": 25292,
"mitre": {
"technique": [
"Account Access Removal"
],
"id": [
"T1531"
],
"tactic": [
"Impact"
]
},
"id": "60122",
"gpg13": [
"7.1"
]
},
"decoder": {
"name": "windows_eventchannel"
},
"input": {
"type": "log"
},
"@timestamp": "2024-10-08T09:47:54.857Z",
"location": "EventChannel",
"id": "1728380874.7448894373",
"timestamp": "2024-10-08T09:47:54.857+0000"
},
"fields": {
"@timestamp": [
"2024-10-08T09:47:54.857Z"
],
"timestamp": [
"2024-10-08T09:47:54.857Z"
]
}

}

What is triggering this event? Is it some Windows-garbage? Can I disable some rules?

This occurs some times troughout the day on different servers.

Cheers chic

Md. Nazmur Sakib

unread,

Oct 8, 2024, 6:49:20 AM10/8/24

to Wazuh | Mailing List

Hi Andrehens Chicfici,

You can check your agent’s queue_size, events_per_second (EPS), and increase the size following the limits shared in the document

https://documentation.wazuh.com/current/user-manual/agent/agent-management/antiflooding.html#throughput-configuration

queue_size can be any number between 1 and 100000

https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/client-buffer.html

But increasing it too much can overwhelm the agent's performance, I will suggest you check on alerts that are continuously triggering and the alert description to find out the eventID and restrict the event from the agent’s ossec.conf. Further, investigate your event viewer why this event is triggering an unusual number of times and try to work on it, when the issue is resolved you can allow collecting logs of that eventID.

At first, you need to review the event logs, to detect anomalies or patterns in the generated events that are responsible for generating lots of logs. You can use this information to reduce false positives. This information can help you understand the root cause of the event and to take appropriate actions to mitigate it.

For example,

If you are receiving Audit Failure events (4673) log from a process called chrome.exe located as C:\Program Files\Google\Chrome\Application\chrome.exe, you can restrict the event from your agent’s ossec.conf.

Go to the ossec.conf of the agent

Run PowerShell as administrator

Open the configuration file with

notepad.exe 'C:\Program Files (x86)\ossec-agent\ossec.conf'

Check you have a configuration like this and add the EventID != 4673 with the configuration of <location>Security</location> inside <localfile> existing configuration.

<location>Security</location>

<log_format>eventchannel</log_format>

<query>Event/System[EventID != 5145 and EventID != 5156 and EventID != 5447 and EventID != 4656 and EventID != 4658 and EventID != 4663 and EventID != 4660 and EventID != 4670 and EventID != 4690 and EventID != 4703 and EventID != 4907 and EventID != 5152 and EventID != 5157 and EventID != 4673 ]

</query>

Save the config file.

Then restart the agent and check if the alert has stopped triggering.

Restart-Service -Name wazuh

Based on your alert you can change your event ID as mentioned above.

You can find the detailed explanation of how the agent's events are buffered in the following documentation: https://documentation.wazuh.com/current/user-manual/agents/antiflooding.html

If you do not see any repetitive alerts enable archive and check if you have any repetitive events on the archive log from that agent.

Ref:https://documentation.wazuh.com/current/user-manual/manager/event-logging.html#archiving-event-logs

Make sure to disable the archive after testing as it generates lots of logs and occupies disk space.

It seems successful network logon and logoff events are little more than “noise “on domain controllers and member servers because of the amount of information logged and tracked. Unfortunately, you can’t just disable successful network logon/logoff events without also losing other logon/logoff events for interactive, remote desktop, etc.

Ref: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624

But I think we can use query to filter some of the unwanted successful logon events using query.

To filter Windows eventchannel events, XPATH format is used to make the queries following the event schema.

Example:

Assuming that you need to filter out the event with ID 4738 and has the TargetUserName as TEST also the event ID 4722. The configuration would be as follows:

<location>Security</location>

<log_format>eventchannel</log_format>

<query>

\<QueryList\>

\<Query Id="0" Path="Security"\>

\<Select Path="Security"\>*\</Select\>

\<Suppress Path="Security"\>*[System[(EventID=4722)]]\</Suppress\>

\<Suppress Path="Security"\>*[System[(EventID=4738)]] and *[EventData[Data[@Name='TargetUserName'] and (Data ='TEST')]]\</Suppress\>

\</Query\>

\</QueryList\>

</query>

</localfile>

Ref: https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#query

https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-schema?redirectedfrom=MSDN