Integration Wazuh and Azure isn't working with Azure diagnostics query.

[X0rb1t]

I'm trying to integrate Wazuh + Azure, but we encountered an obstacle, we were unable to return the AzureDiagnostics query logs, so I know that in the Wazuh manager there are some decoders and rules specific to Azure, but I believe that these configurations should only work for queries such as: AuditLogs and AzureActivity. I need someone who has already done this integration to help me, please!!! We've tried everything, but nothing works.

[CarlosRS9]

Hi @0xC03LH0,

Wazuh is not limited only to AuditLog or AzureActivity queries. Wazuh is compatible with any query as long as it is a valid Log Analytics query. Once this has been clarified, allow me to help you determine what might be going on.

First of all, I suggest you verify from your Log Analytic Workspace in Azure that the query returns values, to ensure that you have configured the log export correctly and that there is data for the dates you want.

Once this has been confirmed the next step is to enable debug mode to determine if there are any problems or if everything is working correctly.

To enable debug mode simply add the following line to the WAZUH_PATH/etc/local_internal_options.conf file:

wazuh_modules.debug=2

To complete the debug mode activation you will need to restart the Wazuh service. Once done, look for any useful error, warning or info messages in Wazuh > Management > Logs if using the Wazuh UI or WAZUH_PATH/logs/ossec.log from the host itself.

The most relevant information can be found in WAZUH_PATH/logs/azure-logs.log. I'm afraid this is a file that you can't access from the UI, but will have to access from the host itself. This file has been unified with ossec.log in Wazuh 4.4, but until then you will have to look it up on the host if you are using 4.3 or lower.

Those files should give you information to determine if the module is running as expected or if there is some errors with the configuration.

The explanation for this behaviour, in case the module is running without error or warnigs, would be that the logs are not matching any existing rules. Check all of the above and let me know if that's the case, so I can continue to help you with the next steps.

[X0rb1t]

Good afternoon, I performed the tests that were requested, so I noticed that when analyzing the WAZUH_PATH/logs/azure-logs.log, the following error appeared:

12/13/2022 11:48:39 AM INFO: AZURE Azure Log Analytics starting.
12/13/2022 11:48:39 AM INFO: AZURE Log Analytics: Getting authentication token.
12/13/2022 11:48:39 AM INFO: AZURE [MY API] was not found in /var/ossec/wodles/azure/last_dates.json for log_analytics
12/13/2022 11:48:39 AM INFO: AZURE Log Analytics: The search starts for query: 'AzureDiagnostics | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-11-30T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z) '

Also, I had a look at the rules and decoders files, so I noticed that there is only one default rule for Azure:

<group name="azure">

  <rule id="87801" level="3">
    <decoded_as>json</decoded_as>
    <field name="azure_tag">azure-log-analytics</field>
    <description>Azure: Log analytics</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87802" level="3">
    <decoded_as>json</decoded_as>
    <field name="azure_tag">azure-ad-graph</field>
    <description>Azure: AD $(activity)</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87803" level="3">
    <decoded_as>json</decoded_as>
    <field name="azure_tag">azure-storage</field>
    <description>Azure: Storage</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87804" level="3">
    <decoded_as>azure-storage</decoded_as>
    <description>Azure: Storage</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87810" level="3">
    <if_sid>87801</if_sid>
    <field name="Type">AzureActivity</field>
    <description>Azure: Log analytics activity</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87811" level="3">
    <if_sid>87810</if_sid>
    <field name="OperationName">\.+</field>
    <description>Azure: Log analytics: $(OperationName)</description>
    <options>no_full_log</options>
  </rule>

  <rule id="87813" level="3">
    <if_sid>87803</if_sid>
    <field name="operationName">\.+</field>
    <description>Azure: Storage: $(OperationName)</description>
    <options>no_full_log</options>
  </rule>
</group>

So as I told you, we already tried to create only rules, for the treatment of the logs, and even then it didn't work.

[CarlosRS9]

Good afternoon, I performed the tests that were requested, so I noticed that when analyzing the WAZUH_PATH/logs/azure-logs.log, the following error appeared:

There are no error in that snippet. That INFO message only indicates that it was the first time this query was executed and it was necessary to register it in the database. This is normal behaviour.

There is no data available

It is possible that there is no data available for the given query. Please, copy your query and run it in your Azure environment using the corresponding Log Analytics Workspace to check that there is indeed data to obtain. If the query does not return anything from Log Analytics it means that there is no data to process and Wazuh will not be able to fetch anything. Here is your query:

AzureDiagnostics | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-11-30T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z)

If this is not the case, then check if the module is processing data and the data is triggering alerts.

Checking if logs are being processed

The easiest way to check if the logs are being processed, regardless of the service type configured and regardless of whether alerts are being generated or not is by using the logall parameter. This parameter must be enabled in the ossec.conf configuration.

To understand how the logall parameter works it is necessary to learn about the flow that is followed when processing a log until the corresponding alert is displayed in the Wazuh UI. It is as follows:

1. The module downloads the logs available in Azure using the query.
2. The downloaded logs are sent to the analysis engine in the form of Events.
3. The analysis engine evaluates these events and compares them with the different rules available. If the event matches any of the rules an alert is generated, which is what ultimately is shown in the Wazuh UI.

With this in mind, it is possible to make use of the logall. When this option is enabled, Wazuh stores into WAZUH_PATH/logs/archives/archives.logs file every event sent to the analysis engine whether they tripped a rule or not. By checking this file it is possible to determine if the Azure events are being sent to the analysis engine and therefore working properly.

Note: Don't forget to disable the logall parameter once the troubleshooting has finished. Leaving it enabled could result in high disk space consumption.

Let me know if there are events present in your archives.log. It that's the case then I'll show you how to check these events using our wazuh-logtest tool to determine which decoders and rules are being used for those particular events.

I hope this helps. Let us know if you need further assistance.

[X0rb1t]

Good afternoon, perform the activation of logall, I visualized the generated logs, using the command: cat archives.log | grep "AzureDiagnostics" | head -1 . The following information appeared in bash:

[root@azu-0113-appspo bin]# ./wazuh-logtest
Starting wazuh-logtest v4.3.8
Type one log per line

2022 Dec 15 16:38:18 azu-0113-appspo->/var/log/audit/audit.log type=SYSCALL msg=audit(1671133097.028:42196643): arch=c000003e syscall=59 success=yes exit=0 a0=7fea3c0008e0 a1=7fea3c000cd0 a2=7ffd26256968 a3=7fea6959c4e0 items=3 ppid=7196 pid=7212 auid=4294967295 uid=0 gid=988 euid=0 suid=0 fsuid=0 egid=988 sgid=988 fsgid=988 tty=(none) ses=4294967295 comm="azure-logs" exe="/usr/bin/bash" subj=system_u:system_r:unconfined_service_t:s0 key="auoms" type=EXECVE msg=audit(1671133097.028:42196643): argc=17 a0="/bin/sh" a1="wodles/azure/azure-logs" a2="--log_analytics" a3="--la_id" a4="ID" a5="--la_key" a6="KEY" a7="--la_tenant_domain" a8="TENANT NAME" a9="--la_tag" a10="azure-diagnostics" a11="--la_query" a12="AzureDiagnostics" a13="--workspace" a14="WORKSPACE" a15="--la_time_offset" a16="24d" type=CWD msg=audit(1671133097.028:42196643):  cwd="/var/ossec" type=PATH msg=audit(1671133097.028:42196643): item=0 name="wodles/azure/azure-logs" inode=25182286 dev=fd:05 mode=0100750 ouid=0 ogid=988 rdev=00:00 obj=system_u:object_r:var_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1671133097.028:42196643): item=1 name="/bin/sh" inode=823 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1671133097.028:42196643): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=8389380 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1671133097.028:42196643): proctitle=2F62696E2F736800776F646C65732F617A7572652F617A7572652D6C6F6773002D2D6C6F675F616E616C7974696373002D2D6C615F69640031306264643334622D383563382D343965372D613432352D653865313330346463663431002D2D6C615F6B65790077566138517E705555736C4C343862302E3657564B7A62507976

**Phase 1: Completed pre-decoding.
full event: '2022 Dec 15 16:38:18 azu-0113-appspo->/var/log/audit/audit.log type=SYSCALL msg=audit(1671133097.028:42196643): arch=c000003e syscall=59 success=yes exit=0 a0=7fea3c0008e0 a1=7fea3c000cd0 a2=7ffd26256968 a3=7fea6959c4e0 items=3 ppid=7196 pid=7212 auid=4294967295 uid=0 gid=988 euid=0 suid=0 fsuid=0 egid=988 sgid=988 fsgid=988 tty=(none) ses=4294967295 comm="azure-logs" exe="/usr/bin/bash" subj=system_u:system_r:unconfined_service_t:s0 key="auoms" type=EXECVE msg=audit(1671133097.028:42196643): argc=17 a0="/bin/sh" a1="wodles/azure/azure-logs" a2="--log_analytics" a3="--la_id" a4="10bdd34b-85c8-49e7-a425-e8e1304dcf41" a5="--la_key" a6="wVa8Q~pUUslL48b0.6WVKzbPyv2OGMZ4NDTDCa_D" a7="--la_tenant_domain" a8="santandercaceiscloud.onmicrosoft.com" a9="--la_tag" a10="azure-diagnostics" a11="--la_query" a12="AzureDiagnostics" a13="--workspace" a14="5121b7c3-8952-4063-8924-05f2481a835b" a15="--la_time_offset" a16="24d" type=CWD msg=audit(1671133097.028:42196643):  cwd="/var/ossec" type=PATH msg=audit(1671133097.028:42196643): item=0 name="wodles/azure/azure-logs" inode=25182286 dev=fd:05 mode=0100750 ouid=0 ogid=988 rdev=00:00 obj=system_u:object_r:var_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1671133097.028:42196643): item=1 name="/bin/sh" inode=823 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1671133097.028:42196643): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=8389380 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1671133097.028:42196643): proctitle=2F62696E2F736800776F646C65732F617A7572652F617A7572652D6C6F6773002D2D6C6F675F616E616C7974696373002D2D6C615F69640031306264643334622D383563382D343965372D613432352D653865313330346463663431002D2D6C615F6B65790077566138517E705555736C4C343862302E3657564B7A62507976'
        timestamp: '2022 Dec 15 16:38:18'

**Phase 2: Completed decoding.
        No decoder matched.

So we can see that the decoders and rules to handle this type of logging are not present, correct? or should we do more other tests?

[nico-stefani]

@0xC03LH0 This log isn't one obtained from azure is a SYSCALL type.

Could you check this from the previous comment?

There is no data available It is possible that there is no data available for the given query. Please, copy your query and run it in your Azure environment using the corresponding Log Analytics Workspace to check that there is indeed data to obtain. If the query > does not return anything from Log Analytics it means that there is no data to process and Wazuh will not be able to fetch > anything. Here is your query:

AzureDiagnostics | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-11-30T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z)

[X0rb1t]

Hello, @nico-stefani I put exactly like this in OSSEC.conf, <query>AzureDiagnostics</query>, so when looking at the azure-logs.log, wazuh apparently concatenates this command automatically, so the query looks like this: AzureDiagnostics | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-11-30T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z).

[nico-stefani]

But, could you try this query directly in the Azure console and check if any logs are return?

[X0rb1t]

I tried running this query on Azure: AzureDiagnostics | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-21T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z), therefore returns the following error: Well, I think the query: AzureDiagnostcs is concatenated with | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-11-30T18:42:31.448184Z) | limit 10 | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z), because in the OSSEC.conf file, there is the <time_offset> tag: what do you think?

[nico-stefani]

As Carlos said this means that there is no data to process and Wazuh will not be able to fetch anything. Because this query is exactly the same that Wazuh will be using, varying the TimeGenerated values. Please review your azure configuration and try to obtain data with the query, once this works Wazuh should be capable of fetching logs.

[X0rb1t]

Good afternoon, we tested the query as requested. But it is worth mentioning that we had already done this test, so as I said, we looked at the logs in the azure-logs.log file, and we observed that it concatenates the AzureDiagnostics query with these commands: | order by TimeGenerated asc | where TimeGenerated >= datetime(2022-12-12T14:48:39.864709Z) , so I think this is our mistake.

[zJvco]

Hi.

I'm have the same problem with Azure Diagnostics that @0xC03LH0 said.

The Azure Diagnostics query isn't returning in the wazuh logs, I don't know why. I have to create a decoder and rule to run this query?

[liam-silvatech]

It's affecting the signIn logs for me. I can see in the alerts.json the sign in event, with all the data perfectly.

But running a ruleset test and pasting in that data comes up with on phase 3.

**Phase 3: Completed filtering (rules).
    id: '1002'
    level: '2'
    description: 'Unknown problem somewhere in the system.'
    groups: '["syslog","errors"]'
    firedtimes: '1'
    gpg13: '["4.3"]'
    mail: 'false'

Data is decoded fine.

I've only just started to learn Wazuh, but in the rule it has this;

<rule id="87802" level="3">
    <decoded_as>json</decoded_as>
    <field name="azure_tag">azure-ad-graph</field>
    <description>Azure: AD $(activity)</description>
</rule>

Will it error because activity doesn't exist? Only think this because auditLogs/directoryAudits works as expected. So is auditLogs/signIns failing because a rule is expecting the format of a directory audit?