Rule 92656 - Single Windows RD Server Triggering Alert

[Jaik Smith]

Hi Everyone,

I recently implemented Wazuh across my domain with multiple customers connecting to individual RD Gateways. All of these implementations connecting to the Gateway over port 443, then the gateway forwards that connection over the internal network over RDP (3389) to the session host. For a small subset of these implementations, that session host is the same server as the gateway, in other words, an all-in-one box. 

The reason I'm posting here today is looking for some guidance for one of these "all in one (AIO)" servers trigger the 92656 alert when a user initiates a connection. 

- Wazuh v4.9.0 REV 07

- The behavior appears to be legitimate to me, and a netstat check on the VM looks like the established connections on the other AIO boxes that are not triggering the 92656 rule. 

- When comparing the specific login events for two identical AIO VMs, they look very similar with the exception that the flagged events do not show Geolocation data since the Source IP is a loopback address.

- Looking at the logon event type, the flagged logon events are always type 10, which is a Remote Interactive session. 

- This is flagging for some of the end users sessions, as well as my sessions. Both internal 3389 traffic has been flagged, as well as my traffic emulating the end users experience over 443 through the RDGateway. 

Could this be a false positive that I need to enter an exception for? I just can't wrap my head around why these alerts are not triggering on the other AIO VMs since they have the same exact configurations on the VM side... 

Any further details you need that will be helpful I'm happy to provide, and any advice you can provide would be much appreciated!

 

Thanks

[John Adewale Olatunde]

Hello Jaik Smith

Do you mean, one of the devices trigger the 92656 alert while other devices do not trigger the alert even though they are of the similar configuration? 

If this is the case, it may have to do with the source IP address, the 92656 alert depends on 2 criteria
-  the logon type which is 10 

- the IP address field must match either the IPv6 loopback address (::1) or the IPv4 loopback address (127.0.0.1)  

These are the conditions that ensure this alerts is triggered

Let me know if this helps

[Jaik Smith]

Hi John,

Thanks for the explanation. In these logs, the logontype is indeed 10,  and the ipAddress value is the private IPv6 Address of that VM. This does make sense to me in terms of how one of these AIO VMs operate, but the odd thing I cannot understand is why one VM is triggering this critical severity alert, while another VM, generating nearly the exact same log for the exact same operation, does not trigger the alert.  

Attached are the logs for each scenario in case that is helpful.

Do you have any insight on how I can correct this? Either configuring the system to fix the loopback, or configuring the logging to not alert us of this specific problem?

Thanks,

Jaik

[Jaik Smith]

It seems that because my account is new, the moderators need to approve all my responses, which is leading to delays. Bumping this thread so it doesn't get forgotten :)

[John Adewale Olatunde]

Hello Jaik

I believe the issue you are experiencing is similar to this https://github.com/wazuh/wazuh/issues/20188

The problem is with the regex used in the rule. Since the alerting IP address "fe80::198:60c1:a34f:2380" contains "::1," it triggers the alert on the alerting VM, this is a false positive. This is a known issue that will be fixed; however, you can use the proposed fix in the GitHub issue.