Hosts tab in SIEM and WEF

There is Hosts tab in SIEM. I think nobody in Enterprise uses Winlogbeat on every Windows hosts. It is standard to use collector for logs and send Logs using Windows Event Forwarding on it. So, in field Host it will be name of collector. Or just collect logs from AD DC.
But in SIEM tab "Hosts" i defenetly want to see hostname of Users Windows stations.
So, how to fix it?I do not want to rename fields, because it breakes existing Scheme. Maybe in future you will change the logic of this page?
What is the best solution to see real hosts on this SIEM tab?

1 Like

We are also using WEF and Winlogbeats and seeing only the WEF host in the Hosts page under SIEM. Would love to either find out how to get the individual hosts to show up, if it's a feature request, or a bug.

By default, Winlogbeat adds the current hostname as host.name which is then displayed by the All Hosts table. Unfortunately, that's not the right thing when reading forwarded events.

What you can do is overwrite host.name with winlog.computer_name (I think that contains the hostname of the machine the events came from, but I'm not sure).

I haven't tested the following, but think it should work (in winlogbeat.yml):

processors:
  - script:
      lang: javascript
      id: forwarded_hostname
      source: >
        function process(event) {
          event.Put("host.name", event.Get("winlog.computer_name"));
        }

We've discussed some ways of making this easier, but this is probably the best we can do for now.

3 Likes

Thank you. I will try to check it!

What would the fix be for a Linux/CentOS environment. using Filebeat and/or Auditbeat

Did this work when you tested it? I'm trying to do the same and doesn't seem to be do anything.

@candre.dabney The question here is about WEF (Windows Event Forwarding). I assume you mean something else? Do you mind opening a separate topic?

@crickes The script is supposed to overwrite host.name with winlog.computer_name. Do you have these in your events? Do you see any warnings/errors when running Winlogbeat with the script? Can you maybe post an example document from your environment?

Hi. Yes both these fields are present but I'm not convinced we've got the processor defined correctly. As an alternative, I've used an ingest pipeline to remap these fields and that worked ok, but I'd rather figure out how to make the processor work in winlogbeat. I can't post an example document, but I can confirm that 'host.name' currently refers to our Windows Event Collector server where winlogbeat is running, and 'winlog.computer_name' contains the name of the source of the event. With this script in place, i would expect them to bother report the latter value.

sure I don't mind. Also just a heads up, I sent you a message explaining the issue as well.

This is the section of the yml file now with your suggested code. Is it in the right place?

#======================= Winlogbeat specific options ==========================
winlogbeat.event_logs:
  - name: Application
    ignore_older: 30m
  - name: Security
    ignore_older: 30m
  - name: System
    ignore_older: 30m
  - name: ForwardedEvents   
    processors:
      - script:
          when.equals.winlog.channel: Security
          lang: javascript
          id: security
          file: ${path.home}/module/security/config/winlogbeat-security.js  
      - script:
          lang: javascript
          id: forwarded_hostname
          source: >
            function process(event) {
              event.Put("host.name" , event.Get("winlog.computer_name"));
            }

@crickes Yeah, that might have worked. I think what's happening is that the Beat is overwriting host.name after the script executes. Can you try putting it into the top-level processors section (outside winlogbeat.event_logs) like this?

processors:
  - script:
    lang: javascript
    id: forwarded_hostname
    source: >
      function process(event) {
        var channel = event.Get("winlog.channel");
        if channel && channel === "ForwardedEvents" {
          event.Put("host.name" , event.Get("winlog.computer_name"));
        }
      }

Thanks for an example. Add some lines to move host field to observer.

processors:
  - script:
    lang: javascript
    id: forwarded_hostname
    source: >
      function process(event) {
        var channel = event.Get("winlog.channel");
        if channel && channel === "ForwardedEvents" {
          event.Put("observer.hostname" , event.Get("host.name"));
          event.Put("observer.type" , "forwarder");
          event.Put("host.name" , event.Get("winlog.computer_name"));
        }
      }
1 Like

Hello! I have tested it now and it doesn't work. I get an error when start winlogbeat (7.1.1 version)
I try my and yours variants. But it works without "processors" block.
fa9e-7e60-e47a-5733

It is full config:

winlogbeat.event_logs:
  - name: ForwardedEvents
    forwarded: true
    ignore_older: 168h

processors:
  - script:
    lang: javascript
    id: forwarded_hostname
    source: >
      function process(event) {
        var channel = event.Get("winlog.channel");
        if channel && channel === "ForwardedEvents" {
          event.Put("host.name" , event.Get("winlog.computer_name"));
        }
      }

output.logstash:
  hosts: ["skynet-elk-8.i:5045"]

@smerzlyakov Sorry, the script processor was added in 7.2.0 so is not yet available in your version. Can you use a newer version?

In theory yes, but it a little bit difficult. I need to read all migration guides and i think ECS is changed, so i will have troubles with indexes.
Is there another option?If no, i will try to begin update process. By the way, can you give me a link how to prepare for upgrading?

@smerzlyakov In general, we try to maintain backwards compatibility between minor releases. The release notes have very few changes for Winlogbeat between 7.1 and 7.2 so it most likely should not be a problem. But always good to test, you could run them side-by-side for a while and check for any differences in the data e.g. number of documents and some spot checks of some documents.

We actually don't backport bugfixes to older minors of a major (so there most likely won't be a 7.1.2 bugfix release), so I would recommend going to 7.3.2.

The "upgrade guide" for upgrading between minor versions is very simple: upgrade [...] by simply installing the new release and restarting the Beat process. :slight_smile: