As soon as you can into splunk the data about passwords we can help you search it. But you need to have that data. Splunk as such is "just" a data processing tool. EDIT: Typically querying for default credentials is part of what vulnerability scanners do.

That's the funny part - I don't even have the TA. But I admit I haven't really gotten to the "let's use that data in any way" part which means I didn't care for extractions or CIM-compliance. I wasn't even aware that there is a TA for suricata. I just added an input to pull the events to splunk and that's it.

It's a way of telling Splunk to rename the fields. Normally if you just do | stats values(*) it will name the resulting fields values(fielda), values(fieldb), values(fieldc) and so on. If you just want to see what those values are that's no problem but that's not very convenient to work with such fields later. So if you do | stats values(*) as * The resulting mutivalued fields will be named the same as the original fields which you are summarizing were so instead of values(fielda) you'll still have fielda.  

More words please. Subsearch is getting executed (and its results are substituted) where it's placed. So if you do collect [...] sourcetype=[whatever subsearch you come up with] It will work. But that will give you one static value for the whole collect command. If you want to dynamically assign the "destination" sourcetype per each event separately, you must use the hec format.

That's interesting though because my whole config for ingesting suricata's eve.log boils down to this: [monitor:///var/log/suricata/eve.json] disabled = false host = backup index = net sourcetype = suricata I don't even have anything configured for the suricata sourcetype. It just automatically gets parsed as json. I should get it configured more reasonably but it's my home lab server so I don't mind.

in a search of all time on the GUI nothing came up. Checked SplunkD on the server it has Failed to Parse TImeStamp in first MAX_TIMESTAMP_LOOKHEAD ....defaulting to timestamp of previous event...context: source=var/log/suricata.eve. It also complains about too many events with the same timestamp. So do we need to add json_no_timestamp somehwere  maybe in a props file? Wouldn't the app tell it how to parse it?    

Blacklisted events are not logged nor is there a log message when an event is blacklisted.  Therefore, there is nothing to search.  If the event exists on your Windows server and doesn't exist in Splunk then the blacklisting is successful.