Yes, QRadar is great. But sometimes its showing details that are plain wrong, cause its also great when it fails :-)
Of course we do know its all our own fault cause when you parse false data in you always get false data out right? So here is the secret about windows logs and IP addresses.
The story starts when my team member found this KB entry of June 2022. This is exactly what we see in our production system he said. The KB entry about wincollect contains everything you need to know. I didn't know about this deficiency and I found it hard to believe. However its still valid in 7.5.0 at all fix levels.
WinCollect: Events display the IP address of the WinCollect agent as the source or destination (document number 251675)
Question
Why do some Windows events that are remotely polled by WinCollect unexpectedly report a Source and Destination IP address of the WinCollect agent itself?
Cause
Many Windows events contain no source or destination IP address information. When no source or destination can be determined, QRadar uses the IP address found in the event payload header as the source IP address. If there is no IP address in the header, QRadar uses the packet IP address, which is the address of the WinCollect agent. This issue can cause multiple events to appear as they have a source or destination IP address of the WinCollect agent.
Answer
Currently, the only solution would be to use the IP address of the remote Windows Server. The Log Source Identifier in the Log Source Configuration for any log source needs to be correct IP address. If you experience issues with events that do not appear to parse or categorize properly, confirm the event types are supported in the QRadar DSM Guide or contact QRadar Support for assistance.
So we could end up here but I thought it may help to explain a bit more about the background and root cause of the problem. At least my colleague asked what we need to do in order to fix this windows server log.
Lets assume you have a win collector at IP address 10.0.248.194 and a wincollect log source at srvtest10. Of course you defined the log source using the computer name in order to be independent from IP address changes. Whenever a new process gets created a success audit event id 4688 comes in cause its part of the NSA filter definition being used and of your audit policy for windows server. Inside your payload srvtest10 will be part of the logheader and as well being used for originating computer attribute. However there will be no source address field inside payload = case A. However when an event id 5145 comes in which is part of the NSA filter as well, payload will contain a source address IP field using a valid number, in this case 10.84.4.211 = case B (marked line). The result of the search for all logevents of your wincollect log sources will look like this:
What you see is that part of the events coming in show the correct source IP address while others show the IP address of the win collector host. Of course destination IP is always the win collector IP. So how do we get this fixed? Simply by using the numeric source IP address rather than the hostname. This will change the log header field being sent by the agent and subsequently show the correct source IP address for all type of events regardless if they contain a valid source address IP field or not. So far so good. But help! where is the hostname gone you may ask? Of course you can always do an internal DNS server lookup or ask your asset DB. The most effective way however is to use the machine identifier property which can be used in rules and searches
Only part of the events show the correct source IP address while others show the source IP address of the win collector host. Of course destination IP is always the win collector IP. So how do we get this fixed? Simply by using the numeric source IP address rather than the hostname when adding the logsource. This will change the log header field being sent by the agent and subsequently show the correct source IP address for all type of events regardless if they contain a valid source address IP field or not. So far so good. But help where is the hostname gone you may ask? Of course you can always do an internal DNS server lookup or ask your asset DB. The most effective way however is to use the machine identifier property which can be used in rules and searches.