filtering in rule for agent.labels.tenant

[ccM]

Hi,

we want to use different custom rules for different customers in the same environment. For this i have tried to implement a rule like that:

<rule id="100005" level="0">
    <if_sid>92910</if_sid>
     <field name="win.eventdata.sourceImage" type="pcre2">^$dellupdate</field>
     <field name="win.eventdata.targetImage" type="pcre2">^$explorer</field>
     <field name="win.eventdata.grantedAccess" type="pcre2">(?i)0x1f3fff</field>
     <field name="agent.labels.tenant" type="pcre2">(?i)customer</field>
 </rule>

Since i have added the last line
<fied name="agent.labels.tenant" type="pcre2">(?i)customer</field>
The rule does not match anymore. I have also tried file name="labels.tenant" but still  no luck.
Without the customer-line the rules workes without any problems and the field name is double checked of course by me.

Does anybody have any suggestions why the rule does not work?

Thanks :)

[Christian Borla]

Hi ccM
I hope you are well.
Do you have any example log from archives.json? here you can find how to enable it.
I would like to see how the complete message arrives, I can't find the ‘labels’ option in the rule syntax documentation. I understand that you need to apply a filter similar to how location works.
If you get the events, it will make it easier to search, I will keep analysing and try to do a local test to see if the decoders/rules have access to the label field for use in processing.

Regards.

[ccM]

Hi Christan,
thanks for asking im fine hope you too;)

here is an example log.

{

  "_index": "wazuh-alerts-4.x-2024.08.19",

  "_id": "Fa3zapEBLOogKozRp9l2",

  "_version": 1,

  "_score": null,

  "_source": {

    "cluster": {

      "node": "wazuh-manager-worker-1",

      "name": "wazuh"

    },

    "input": {

      "type": "log"

    },

    "agent": {

      "ip": "IP",

      "name": "computer",

      "id": "018",

      "labels": {

        "tenant": "customer"

      }

    },

    "manager": {

      "name": "wazuh-manager-worker-1"

    },

    "data": {

      "win": {

        "eventdata": {

          "grantedAccess": "0x1f3fff",

          "targetProcessId": "10492",

          "sourceUser": "NT-AUTORITÄT\\\\SYSTEM",

          "targetImage": "C:\\\\WINDOWS\\\\Explorer.EXE",

          "sourceProcessGUID": "{4622eb84-1640-66bd-8a01-000000004f00}",

          "callTrace": "C:\\\\WINDOWS\\\\SYSTEM32\\\\ntdll.dll+9da24|C:\\\\WINDOWS\\\\System32\\\\KERNELBASE.dll+338ae|C:\\\\WINDOWS\\\\assembly\\\\NativeImages_v4.0.30319_64\\\\System\\\\d1041c08d723edb6b6e187073cdf0a37\\\\System.ni.dll+34f530|C:\\\\WINDOWS\\\\assembly\\\\NativeImages_v4.0.30319_64\\\\System\\\\d1041c08d723edb6b6e187073cdf0a37\\\\System.ni.dll+2cd89e|C:\\\\WINDOWS\\\\assembly\\\\NativeImages_v4.0.30319_64\\\\System\\\\d1041c08d723edb6b6e187073cdf0a37\\\\System.ni.dll+2cc445|C:\\\\WINDOWS\\\\assembly\\\\NativeImages_v4.0.30319_64\\\\System\\\\d1041c08d723edb6b6e187073cdf0a37\\\\System.ni.dll+2b2f6e|C:\\\\WINDOWS\\\\assembly\\\\NativeImages_v4.0.30319_64\\\\System\\\\d1041c08d723edb6b6e187073cdf0a37\\\\System.ni.dll+2b2635|UNKNOWN(00007FF89F99018B)",

          "sourceThreadId": "7864",

          "targetProcessGUID": "{4622eb84-f86f-66be-bb10-000000004f00}",

          "utcTime": "2024-08-19 14:04:14.150",

          "ruleName": "technique_id=T1055.001,technique_name=Dynamic-link Library Injection",

          "sourceProcessId": "956",

          "sourceImage": "C:\\\\Program Files (x86)\\\\Dell\\\\UpdateService\\\\ServiceShell.exe",

          "targetUser": ""

        },

        "system": {

          "eventID": "10",

          "keywords": "0x8000000000000000",

          "providerGuid": "{5770385f-c22a-43e0-bf4c-06f5698ffbd9}",

          "level": "4",

          "channel": "Microsoft-Windows-Sysmon/Operational",

          "opcode": "0",

          "message": "\"Process accessed:\r\nRuleName: technique_id=T1055.001,technique_name=Dynamic-link Library Injection\r\nUtcTime: 2024-08-19 14:04:14.150\r\nSourceProcessGUID: {4622eb84-1640-66bd-8a01-000000004f00}\r\nSourceProcessId: 956\r\nSourceThreadId: 7864\r\nSourceImage: C:\\Program Files (x86)\\Dell\\UpdateService\\ServiceShell.exe\r\nTargetProcessGUID: {4622eb84-f86f-66be-bb10-000000004f00}\r\nTargetProcessId: 10492\r\nTargetImage: C:\\WINDOWS\\Explorer.EXE\r\nGrantedAccess: 0x1F3FFF\r\nCallTrace: C:\\WINDOWS\\SYSTEM32\\ntdll.dll+9da24|C:\\WINDOWS\\System32\\KERNELBASE.dll+338ae|C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\System\\d1041c08d723edb6b6e187073cdf0a37\\System.ni.dll+34f530|C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\System\\d1041c08d723edb6b6e187073cdf0a37\\System.ni.dll+2cd89e|C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\System\\d1041c08d723edb6b6e187073cdf0a37\\System.ni.dll+2cc445|C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\System\\d1041c08d723edb6b6e187073cdf0a37\\System.ni.dll+2b2f6e|C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\System\\d1041c08d723edb6b6e187073cdf0a37\\System.ni.dll+2b2635|UNKNOWN(00007FF89F99018B)\r\nSourceUser: NT-AUTORITÄT\\SYSTEM\r\nTargetUser: \"",

          "version": "3",

          "systemTime": "2024-08-19T14:04:14.1604540Z",

          "eventRecordID": "605950",

          "threadID": "7172",

          "computer": "",

          "task": "10",

          "processID": "5252",

          "severityValue": "INFORMATION",

          "providerName": "Microsoft-Windows-Sysmon"

        }

      }

    },

    "rule": {

      "firedtimes": 60,

      "mail": true,

      "level": 12,

      "description": "Explorer process was accessed by C:\\\\Program Files (x86)\\\\Dell\\\\UpdateService\\\\ServiceShell.exe, possible process injection",

      "groups": [

        "sysmon",

        "sysmon_eid10_detections",

        "windows"

      ],

      "mitre": {

        "technique": [

          "Process Injection"

        ],

        "id": [

          "T1055"

        ],

        "tactic": [

          "Defense Evasion",

          "Privilege Escalation"

        ]

      },

      "id": "92910"

    },

    "location": "EventChannel",

    "decoder": {

      "name": "windows_eventchannel"

    },

    "id": "1724076236.258917286",

    "timestamp": "2024-08-19T14:03:56.559+0000"

  },

  "fields": {

    "timestamp": [

      "2024-08-19T14:03:56.559Z"

    ]

  },

  "highlight": {

    "cluster.name": [

      "@opensearch-dashboards-highlighted-field@wazuh@/opensearch-dashboards-highlighted-field@"

    ]

  },

  "sort": [

    1724076236559

  ]

}

[Christian Borla]

Hello ccM
As far as I could test locally the rule does not have access to the agent block.

 ‘agent": {

      ‘ip": “IP”,
      ‘name": “computer”,
      ‘id": “018”,
      ‘labels": {
        ‘tenant": ’customer’
      }
    },

extra of what is data, you can only to the ‘location’ sector: ‘EventChannel’, and of course in case of using some time condition to the timestamp sector.

Looking for conditions referring to the agent in the rules sector, I found <same_agent/>, or <different_agent/>, but when I used them I got the following message.

# /var/ossec/bin/wazuh-control start
2024/08/19 20:05:00 wazuh-analysisd: WARNING: Detected a deprecated field option for rule, same_agent is not longer available.
This cannot be used either.

One option is to use a CDB list, where you will keep the ip's of a client's agents, then just by updating the values in that list you can modify the conditions of the rule. 

Here you also have another option, link

Currently wazuh is working on a new version of the rules engine, which will allow this kind of comparison and many more functionalities, this is the new engine which is still under development.

I hope it helps.
Regards.

[wazuh]

Using Ip's might not be the best option as IP addresses can change, another work around would be to utilize the dynamic <location> field to reference agent names in a variable. First you'd need to create a variable that has all the agent names that belong to the tenant at the top the rules file as such:
<var name="tenant1">agent_name_1|agent_name_2|agent_name_3|agent_name_4-</var>
<var name="tenant2">agent_name_5|agent_name_6|agent_name_7|agent_name_8-</var>

now you can reference the variables in each rule group using <location>:

<group name="exceptions rule group name,">

<rule id="100005" level="0">
    <if_sid>92910</if_sid>
     <field name="win.eventdata.sourceImage" type="pcre2">^$dellupdate</field>
     <field name="win.eventdata.targetImage" type="pcre2">^$explorer</field>
     <field name="win.eventdata.grantedAccess" type="pcre2">(?i)0x1f3fff</field>

     <location>$tenant1</location>

     <description> Exception for DellUpdate for tenant1</description>
 </rule>
</group>

[ccM]

should the option provided by wazuh also work with CDB lists? So I do not have to define the rule in every single rule 

[wazuh]

I've tried with cdb lists with no luck before but you can try yourself as well (though i've tried using the  location field and agent name for it, so if you try with IP might work for you), and this variable does not need to be defined in every single rule, you can place the variable outside of the <group> </group> so it works for every single group of custom rules you have. it will work similarly as cdb list would. once you have the <var> defined you just need to reference it in the <location> field in any rule you create

[ccM]

We are using seperate rule files for each rule. I have tried but obviously variables are only saved in the same file also with CDB lists i had no luck.

Does anyone see a chance how to implement the tenant in each rule file without defining the variable in each file?

[Christian Borla]

Hi ccM
If you want we can analyse the use case of the cdb list that didn't work for you, currently we are not working on the inclusion of the tenant for the rules, what is being implemented directly is a new engine.
If you think we should implement the tenat feature, you could always open an issue with your feature request in https://github.com/wazuh/wazuh and we will evaluate with the team how and when to implement it.

Regards.

[ccM]

Hi Christan,

I have created a a CDB List "customer_tenant" with this scheme 
Key: "TestAgentName" Value: "agent.name"
Key: "TestAgentName2" Value: "agent.name"

and implemented the rule like this 

<rule id="100005" level="0">
    <if_sid>92910</if_sid>
     <field name="win.eventdata.sourceImage" type="pcre2">^$dellupdate</field>
     <field name="win.eventdata.targetImage" type="pcre2">^$explorer</field>
     <field name="win.eventdata.grantedAccess" type="pcre2">(?i)0x1f3fff</field>

     <list field="agent.name" lookup="match_key">etc/lists/customer_Tenant</list>
    <description>Exception RuleID 92910: Explorer process was accessed by trusted application with grantedAccess 0x1f3fff, possible process injection</description>
 </rule>

But alerts still trigger, any ideas what I might doing wrong? Thanks for help
Are there any plans to implement tenant based rules in the new wazuh 5.0 rule engine until now? Thanks again

[ccM]

The CDB List is called "customer_Tenant" of course

[ccM]

Also had no luck with CDB lists with that scheme
Key: "TestAgentName"
Key: "TestAgentName2"
and the same rule like above.

[Christian Borla]

Hi ccM
I hope you are well!
Here you can find an example test, I choose a different event because I can test it with the wazuh-logtest tool, and so it is easier to see how the engine that processes the events works.

Example event
Oct 14 11:12:38 test sudo[355]:  zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=testuser ; COMMAND=/opt/zimbra/libexec/zmmailboxdmgr status


Testing it with wazuh-logtest tool

```
# /var/ossec/bin/wazuh-logtest
Type one log per line

Oct 14 11:12:38 test sudo[355]:  zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=testuser ; COMMAND=/opt/zimbra/libexec/zmmailboxdmgr status

** Wazuh-Logtest: WARNING: Detected a deprecated field option for rule, same_agent is not longer available.

**Phase 1: Completed pre-decoding.
full event: 'Oct 14 11:12:38 test sudo[355]:  zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=testuser ; COMMAND=/opt/zimbra/libexec/zmmailboxdmgr status'
timestamp: 'Oct 14 11:12:38'
hostname: 'test'
program_name: 'sudo'

**Phase 2: Completed decoding.
name: 'sudo'
parent: 'sudo'
ftscomment: 'First time user executed the sudo command'
command: '/opt/zimbra/libexec/zmmailboxdmgr status'
dstuser: 'testuser'
pwd: '/opt/zimbra'
srcuser: 'zimbra'
tty: 'unknown'

**Phase 3: Completed filtering (rules).
id: '5403'
level: '4'
description: 'First time user executed sudo.'
groups: '['syslog', 'sudo']'
firedtimes: '1'
mail: 'False'
mitre.id: '['T1548.003']'
mitre.tactic: '['Privilege Escalation', 'Defense Evasion']'
mitre.technique: '['Sudo and Sudo Caching']'
**Alert to be generated.
```


Next, I have created the custom rule with my example record, in this case I have used the rule id 5403, I have also removed the conditions that we already know that they work, and there is no need to test in this case.
I added the custom rule in `/var/ossec/etc/rules/local_rules.xml`

```

<rule id="100005" level="0">

    <if_sid>5403</if_sid>
     <list field="user" lookup="match_key">etc/lists/customer_Tenant</list>
    <description>Exception RuleID 5403: remove alerts from srcuser in cdb list</description>
 </rule>
 ```

The CDB list looks like following, (var/ossec/etc/lists/customer_Tenant)

```
# cat customer_Tenant
command1:
test:
zimbra:
```

Next, change the permissions to have it the same as the other lists.

```
# chmod 660 customer_Tenant
# chown wazuh customer_Tenant
# chgrp wazuh customer_Tenant
```

include the list in the ossec.conf file.

```
  <ruleset>
    <!-- User-defined ruleset -->
<list>etc/lists/customer_Tenant</list>
  </ruleset>
```

And finally resrtart the mananger, and run the test again, with same event.

```
# /var/ossec/bin/wazuh-logtest
Type one log per line

Oct 14 11:12:38 test sudo[355]:  zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=testuser ; COMMAND=/opt/zimbra/libexec/zmmailboxdmgr status

**Phase 1: Completed pre-decoding.
full event: 'Oct 14 11:12:38 test sudo[355]:  zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=testuser ; COMMAND=/opt/zimbra/libexec/zmmailboxdmgr status'
timestamp: 'Oct 14 11:12:38'
hostname: 'test'
program_name: 'sudo'

**Phase 2: Completed decoding.
name: 'sudo'
parent: 'sudo'
ftscomment: 'First time user executed the sudo command'
command: '/opt/zimbra/libexec/zmmailboxdmgr status'
dstuser: 'testuser'
pwd: '/opt/zimbra'
srcuser: 'zimbra'
tty: 'unknown'

**Phase 3: Completed filtering (rules).
id: '100005'
level: '0'
description: 'Exception RuleID 5403: remove alerts from srcuser in cdb list'
groups: '['local', 'syslog', 'sshd']'
firedtimes: '1'
mail: 'False'
```

As you can see the cdb list works, using the value of the srcusr field it found the zimbra name inside the list and applied the rule. here is a name exception, srcuser and user are the same, but what you have to take into account for this case, is that the engine that processes the rules has access to the srcuser field, that's why the cdb list works, in the example you did, the engine that processes the rule doesn't have access to the agent.name field.

On the other hand, the example given by user wazuh is valid, but the problem is that the location field only indicates the address where the messages come from, in this case all the events that are from eventchannel will not be discriminated, which is not useful for your case.

Another option that occurs to me is to use the hostname, either by defining variables or using cdb list, but I see that not all alerts have it.
I don't see that it is easy to solve it at the rules level, this means that alerts will be generated and can be filtered in the UI.
I hope it helps.