this is the configuration in Imperva correct?  webUI or something?  where is it getting sent to?  is this a blackbox Imperva installation or are you running on your own *nix server?  the syslog that is transporting this data is somehow getting a binary version of the header instead of the raw text.   what you have there is the payload, but you need to find the syslog configuration itself and validate the implementation along every link in the chain between Imperva config to Splunk input. ... View more

To search a lookup table with keyword values not tied to fields/columns (field=keyword) just add an artificial _raw event field: | inputlookup uid_host_ip_mac_rolling.csv | eval _raw=tostring(mvjoin((mvappend('uid','host','ip,'mac'))," : ")) | search myuserid OR my-hostname OR myip OR mymac | table _time uid host ip mac | sort - _time you can use any delimiter you want, it doesn't have to be a " : " also the tostring might not be necessary... | eval _raw=tostring(mvjoin((mvappend('uid','host','ip,'mac'))," : ")) ... View more

To setup a simple HoneyPot you need to leverage the Splunk Stream app: https://splunkbase.splunk.com/app/1809/ deploy decoy systems in the network segments you would like to monitor ensure the decoy system hostnames conforms to your standard naming conventions ensure those systems are built using your Gold Image, conform to all your standard security controls, and are updated and patched using your standard patching processes install the Splunk Stream app on the systems configure the Splunk Stream to capture all inbound ports and protocols forward the data from the Splunk Stream app on your decoy systems to your indexers configure an alert against that stream data when events are greater than 0 the SPL should be written to filter out all standard management activity such as the downloading of any updates or scanning by your Vulnerability Management program but ALL other INBOUND activity should be alerted on In theory, since the system serves no legitimate purpose on the network, even a single packet inbound on the system is cause for investigation. If you have written your alert properly should should almost never receive alerts from this stream data unless it is abnormal for the network segment that the system resides in. If somebody is attempting RDP or ssh to a system that serves no purpose that is interesting. If any system other than your whitelisted vulnerability scanners or patch deploment servers is scanning the decoy host that is interesting. Pings to the system are interesting. Detections using this setup can indicate an active breach and attempted reconnaissance and lateral movement by attackers. Prior experience with this deployment has identified several firewall mis-configurations allowing inbound traffic to a network segment that should not have been. These are important detections to identify and remediate for enhanced security posture even if they aren't active attackers in your network. Just becuase it wasn't malicious doesn't mean it wasn't a good find! Cheers! 😄 ... View more