you can use the foreach command to run the same command against a wildcarded field list. so using your example search, it would look something like | inputlookup table2.csv | foreach * [ eval combined_field=mvappend(combined_field,'<<FIELD>>')] | table combined_field | mvexpand combined_field | inputlookup appent=t table1.csv you may need to do some more manipulation to get the combined field name the way you want it. Doc on the foreach command linked below. https://docs.splunk.com/Documentation/Splunk/7.3.1/SearchReference/Foreach ... View more

I'm not sure if there is an elegant way to do that, especially when you're dealing with different columns. Maybe you can start by expanding the csv so that you have the hostname, ip, and fqdns on separate rows with some column to indicate what row they were in. do the join, and then recombine the rows afterwards. This might get you halfway there. |inputlookup testSVB2.csv | streamstats count as row | eval host=mvappend(host,ip,fqdn) | fields - ip fqdn | mvexpand host | join type=left host [|tstats count WHERE index=* AND [ | inputlookup testSVB2.csv | eval host=mvappend(host,ip,fqdn) | fields + host | format ] by host, index, sourcetype] ... View more

You're on the right track there. The issue I see with that is that if you were looking over a 1hr period for recent account creations, the password reset events at the beginning of your window might cause false positives due to account creations possibly being outside your search time range. You could address this by specifying a different time range inside your subsearch. so assuming your normal search window is -1h to now, you can try index=winevents sourcetype="WinEventLog:Security" EventCode=4724 OR EventCode=627 OR EventCode=628 OR EventCode=4723 user="_s*" NOT [search sourcetype="WinEventLog:Security" EventCode=4720 OR EventCode=624 user="_s*" earliest=-2h | fields user] ... View more

According to the map command documentation the behavior you see is normal since the default maxsearches via map is 10. You can increase that manually, but I believe you will still not get the desired output, because the map command is not designed to append events to an existing set of results. One way to get the results you want is to change your base search to search both indexes for events you want then combining them with stats . ex. index=abcde_yudhbc "Sending message to queue" OR index=ajhdahbd_hdhc "Successfully pushed to system " | stats count(eval(index=abcde-yudhbc)) as count by field Modify the stats command with whatever fields you need. ... View more

you'll want to combine all your fields from your csv into one like : [| inputlookup testSVB2.csv | eval host=mvappend(host,ip,fqdn) | fields + host | format] The format at the end might be redundant, but if you do the subsearch on its own without the brackets, the format command allows you to see what the resulting filter is. It'll probably look like ( ( ( host="*hostname1*" OR host="*ip1*" OR host="*fqdn1*" ) ) ) AND ( ( ( host="*hostname2*" OR host="*ip2*" OR host="*fqdn2*" ) ) ) [AND ...] you can also modify the format command delimiters to change the behavior of the subsearch results ... View more

For a better idea on how to attack your problem, what is the schedule frequency and time window of the search? One way to address this is to have a lookup table of your service accounts (or ideally for security monitoring, all accounts) that has the user account creation date available. When the lookup matches the account id, the event will be enriched with the account creation date. Then you can do a simple eval to get the time difference for filtering. This should work as long as that lookup table is being updated more frequently than your alert's scheduled search interval. The Splunk add-on for active directory has an ldapsearch command that can help you build this table http://docs.splunk.com/Documentation/SA-LdapSearch/2.1.7/User/Theldapsearchcommand#Examples The example given is formatted for ingestion into Splunk Enterprise Security's Identity Management, but you could tweak it to your needs. If you're working with tighter tolerances than the lookup option allows (like a real-time search) or insist on having it done in a single search, you could include the account creation events in your base search. Then use eventstats split by account to get your account creation info fields into the password reset events. The downside of this approach is that depending on the amount of events you're dealing with and how big the time window is, it could take a long time to run and maybe even hit time and resource limits. And if that proves to be not a good fit, there's the option of an external script lookup to fetch the account creation time property straight out of AD. ... View more