creating rules for windows events with filter

Dirk Westenhaus

unread,

Mar 14, 2023, 6:00:22 AM3/14/23

to Wazuh mailing list

I am sorry if this has been discussed several times. I have read and tried to follow everything I found, but perhaps I am missing some key understanding and would very much appreciate your help.

So, there's a Wazuh setup and it is receiving events from Windows (and Linux) machines. Some machines are generating a lot of security events of a specific type, namely “Logon failure - Unknown user or bad password”. This is not only generating a lot of events in the log, but also a lot of e-mails, which shall be muted.

Now I want to silence these alerts, but only for specific sources (say, 192.0.2.10). Should be easy, right?

So I am creating a parent rule for rule id 60122 with a low rule level (1) and a filter for the ip address field:

```xml
# /var/ossec/etc/rules/0001-myrules.xml

<group name="test">
<rule id="100014" level="1">
    <if_sid>60122</if_sid>
    <field name="win.eventdata.ipAddress">192.0.2.10</field>
    <description>not alerting about failed logons from $(win.eventdata.ipAddress)</description>
</rule>
</group>
```

(Yes, the actual event I want to catch is “Multiple Logon failures”, but for debugging purposes I think it is easier to use a different event, as it is triggered more often.)

Problem is, that this is not doing anything. It is not creating events for a new rule id 100014, and the unwanted alerts are still being created.

What could I be doing wrong? What are my debugging options?

Christian Borla

unread,

Mar 14, 2023, 6:30:18 AM3/14/23

to Wazuh mailing list

Hi Dirk!
I hope you are doing fine.

Did you try incluiding the custom rule in local_rules.xml file? by default custom rules are included in /var/ossec/etc/rules/local_rules.xml.
Your custom rule looks good, another option is use pcre2 regex engine to match the case, and escaping the dots.

<description>not alerting about failed logons from $(win.eventdata.ipAddress)</description>
</rule>

The idea is crate a child from rule 60122, to trigger a new rule less severity/level if it matches the ip.

This is a similar case rule example.

<rule id="60001" level="0">
<if_sid>60000</if_sid>
<field name="win.system.channel">^Security$</field>
<options>no_full_log</options>
<description>Group of Windows rules for the Security channel</description>
</rule>

If you share an example alert from 60122, I can help you testing it with wazuh-logtest rule.
Let me know if that helps.
Regards.

Dirk Westenhaus

unread,

Mar 14, 2023, 7:14:01 AM3/14/23

to Wazuh mailing list

Hi Christian!

thank you for your speedy response. I, too, hope that you are fine.

I am pretty certain that the rule was being picked up in the myrules.xml file, as the service restart failed when I made errors in this file.

But I moved it to the local_rules.xml file nevertheless, and changed the regular expression as you suggested:

```xml

sudo tail /var/ossec/etc/rules/local_rules.xml -n 7

<field name="win.eventdata.ipAddress" type="pcre2">192\.0\.2\.10</field>
<description>not alerting about failed logons from $(win.eventdata.ipAddress)</description>
</rule>

</group

```

After applying the change, I can see no difference: The events still have the rule level 5 (not 1), and a search for either rule.id=100014 or rule.groups="test" (should this work?) finds nothing.

I happily have exported and cleaned such an event from sensitive data, here it goes:

```json
{
"_index": "wazuh-alerts-4.x-2023.03.14",
"_type": "_doc",
"_id": "8Vup34YBv00neLWtoOP1",
"_score": 1,
"_source": {
    "cluster": {
      "node": "master",
      "name": "wazuh"
    },
    "agent": {
      "ip": "192.0.2.1",
      "name": "AD-DOMAIN-CONTROLLER",
      "id": "002"
    },
    "data": {
      "win": {
        "eventdata": {
          "subjectLogonId": "0x3e7",
          "subjectDomainName": "AD-DOMAIN",
          "ipAddress": "192.0.2.10",
          "authenticationPackageName": "Kerberos",
          "workstationName": "AD-DOMAIN-CONTROLLER",
          "subStatus": "0xc0000064",
          "logonProcessName": "Schannel",
          "keyLength": "0",
          "subjectUserSid": "S-1-5-18",
          "processId": "0x2a0",
          "processName": "C:\\\\Windows\\\\System32\\\\lsass.exe",
          "ipPort": "36056",
          "failureReason": "%%2313",
          "targetUserSid": "S-1-0-0",
          "logonType": "3",
          "subjectUserName": "AD-DOMAIN-CONTROLLER$",
          "status": "0xc000006d"
        },
        "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-5-18\r\n\tKontoname:\t\tAD-DOMAIN-CONTROLLER$\r\n\tKontodomäne:\t\tAD-DOMAIN\r\n\tAnmelde-ID:\t\t0x3E7\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\t\r\n\tKontodomäne:\t\t\r\n\r\nFehlerinformationen:\r\n\tFehlerursache:\t\tUnbekannter Benutzername oder ungültiges Kennwort.\r\n\tStatus:\t\t\t0xC000006D\r\n\tUnterstatus::\t\t0xC0000064\r\n\r\nProzessinformationen:\r\n\tAufrufprozess-ID:\t0x2a0\r\n\tAufrufprozessname:\tC:\\Windows\\System32\\lsass.exe\r\n\r\nNetzwerkinformationen:\r\n\tArbeitsstationsname:\tAD-DOMAIN-CONTROLLER\r\n\tQuellnetzwerkadresse:\t192.0.2.10\r\n\tQuellport:\t\t36056\r\n\r\nDetaillierte Authentifizierungsinformationen:\r\n\tAnmeldeprozess:\t\tSchannel\r\n\tAuthentifizierungspaket:\tKerberos\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 lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler 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": "2023-03-14T10:27:57.289657500Z",
          "eventRecordID": "535458528",
          "threadID": "2648",
          "computer": "AD-DOMAIN-CONTROLLER.DOMAIN",
          "task": "12544",
          "processID": "672",
          "severityValue": "AUDIT_FAILURE",
          "providerName": "Microsoft-Windows-Security-Auditing"
        }
      }
    },
    "rule": {
      "mail": false,
      "level": 5,
      "hipaa": [
        "164.312.b"
      ],
      "pci_dss": [
        "10.2.4",
        "10.2.5"
      ],
      "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": [
        "AC.7",
        "AU.14"
      ],
      "gdpr": [
        "IV_32.2",
        "IV_35.7.d"
      ],
      "firedtimes": 9,
      "mitre": {
        "technique": [
          "Valid Accounts",
          "Account Access Removal"
        ],
        "id": [
          "T1078",
          "T1531"
        ],
        "tactic": [
          "Defense Evasion",
          "Persistence",
          "Privilege Escalation",
          "Initial Access",
          "Impact"
        ]
      },
      "id": "60122",
      "gpg13": [
        "7.1"
      ]
    },
    "id": "1678789678.3115497192",
    "timestamp": "2023-03-14T11:27:58.296+0100",
    "manager": {
      "name": "WAZUH-MANAGER"
    },
    "decoder": {
      "name": "windows_eventchannel"
    },
    "input": {
      "type": "log"
    },
    "@timestamp": "2023-03-14T10:27:58.296Z",
    "location": "EventChannel",
    "GeoLocation": {
      "city_name": "CITY",
      "country_name": "COUNTRY",
      "region_name": "REGION",
      "location": {
        "lon": LON,
        "lat": LAT
      }
    }
},
"fields": {
    "@timestamp": [
      "2023-03-14T10:27:58.296Z"
    ],
    "timestamp": [
      "2023-03-14T10:27:58.296Z"
    ]
}
}
```

Thank you for any help! Kind regards

Christian Borla

unread,

Mar 14, 2023, 10:27:10 AM3/14/23

to Wazuh mailing list

Hi!

I make it works

To realise if it's working it will necessary modify the general alert level of ossec.conf. This way we will see a level 1 alert in alert.json file.

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>12</email_alert_level>
</alerts>

I added following custom rule on /var/ossec/etc/rules/local_rules.xml

<field name="win.eventdata.ipAddress" type="pcre2">127\.0\.0\.1</field>
<description>not alerting about failed logons from</description>
</rule>

After that I made a few failed login attempts. and filter the event by rule id 100014

cat /var/ossec/logs/alerts/alerts.json | grep 100014

The alert generated.

{
"timestamp": "2023-03-14T11:18:11.737-0300",
"rule":
{
"level": 1,
"description": "not alerting about failed logons from",
"id": "100014",
"firedtimes": 2,
"mail": false,
"groups":
[
"local",
"syslog",
"sshd"
]
},
"agent":
{
"id": "001",
"name": "DESKTOP-11111",
"ip": "2803:1A7F:9882:1A7F:5E87:1A7F:650F:1A7F"
},
"manager":
{
"name": "VBox"
},
"id": "1678800091.600008",
"decoder":
{
"name": "windows_eventchannel"
},
"data":
{
"win":
{
"system":
{
"providerName": "Microsoft-Windows-Security-Auditing",
"providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
"eventID": "4625",
"version": "0",
"level": "0",
"task": "12544",
"opcode": "0",
"keywords": "0x8010000000000000",
"systemTime": "2023-03-14T14:18:12.8239987Z",
"eventRecordID": "1079160",
"processID": "1164",
"threadID": "17680",
"channel": "Security",
"computer": "DESKTOP-11111",
"severityValue": "AUDIT_FAILURE",
"message": "Error de una cuenta al iniciar sesión.\r\n\r\nSujeto:\r\n\tId. de seguridad:\t\tS-1-5-18\r\n\tNombre de cuenta...."
},
"eventdata":
{
"subjectUserSid": "S-1-5-18",
"subjectUserName": "DESKTOP-11111$",
"subjectDomainName": "WORKGROUP",
"subjectLogonId": "0x3e7",
"targetUserSid": "S-1-0-0",
"targetUserName": "asus",
"targetDomainName": "DESKTOP-11111",
"status": "0xc000006d",
"failureReason": "%%2313",
"subStatus": "0xc000006a",
"logonType": "2",
"logonProcessName": "User32",
"authenticationPackageName": "Negotiate",
"workstationName": "DESKTOP-11111",
"keyLength": "0",
"processId": "0x4c4",
"processName": "C:\\\\Windows\\\\System32\\\\svchost.exe",
"ipAddress": "127.0.0.1",
"ipPort": "0"
}
}
},
"location": "EventChannel"
}

My mistake was looking for 100014 level 1, without enable level 1 in global configuration.
Let me know if that works for you,
Regards!

Dirk Westenhaus

unread,

Mar 14, 2023, 11:09:53 AM3/14/23

to Wazuh mailing list

Hi Christian,

wow, that's it! All that was missing was an appropriate alert log level in the global configuration. Now I feel a little dumb. But I knew it must have been something like that.

Thanks a thousand tons! :-D

Best regards

Christian Borla

unread,

Mar 14, 2023, 11:44:53 AM3/14/23

to Wazuh mailing list

You are welcome!
Regards.

Reply all

Reply to author

Forward