I am kind of new so I apologize to my ignorance.
What I am trying to do is use the Windows Event Logs EventCode 5156 and 4688
I want to search via 5156, it provides the PID and the Process making the connection. I want to be able to then use the information from the 5156 to find the 4688 for that process which provides its command line arguments. Any ideas?
Sounds like you want a subsearch
Try this
EventCode=4688 [|search EventCode=5156 | fields + Process_ID Application_Name | rename Process_ID as New_Process_ID Application_Name as New_Process_Name]
If you have an index for windows events, it would be good to use that as well. The query turns Process_ID and Application_Name from event 5156 into search terms for event 4688. Since Event 4648 has different field names, we have to rename the fields from 5156.
I am not familiar with these EventCodes, so it could be that instead of New_Process_ID and New_Process_Name, you may need Creator_Process_ID and Creator_Process_Name
Sounds like you want a subsearch
Try this
EventCode=4688 [|search EventCode=5156 | fields + Process_ID Application_Name | rename Process_ID as New_Process_ID Application_Name as New_Process_Name]
If you have an index for windows events, it would be good to use that as well. The query turns Process_ID and Application_Name from event 5156 into search terms for event 4688. Since Event 4648 has different field names, we have to rename the fields from 5156.
I am not familiar with these EventCodes, so it could be that instead of New_Process_ID and New_Process_Name, you may need Creator_Process_ID and Creator_Process_Name
Doesn't this run up against the limit imposed on the number of results that are returned from a subsearch? By default, limits.conf sets that to 10,000, but it can only be increased to 10,500. As written, won't this search miss data if there are more than 10,000 events of EventCode 5156?
Nice, MonkeyK! I must've been tired last night, I kept starting from the 4688 side instead of just going backwards from the 5156 side. This way makes so much more sense!
Thanks! That worked out. I had to adjust the Application name because in the 5156 it uses the Application portion as
\device\harddiskvolume4< path to app >
instead of
c:\
took some manipulation but it works! I appreciate the help!
@dirtyspawn, please accept the answer to mark this question as answered.
Complication - there are multiple 5156 events for each 4688, aren't there? I mean, it's POSSIBLE a new process is created for EACH connection, but it truly seems bizarrely unlikely.
That means you have to either
a) bundle ALL The 5156's that go with the 4688 together (not hard but may have performance implications)
b) only "group" the first 5156 that goes with the 4688 (even easier and with lower performance hit - but probably not what you want)
c) group each 5156 with it's corresponding 4688 with the 5156 duplicated into each (really hard problem? Not sure yet).
d) actually thought of another way - if we built a lookup table of the 4688 events, since there should be far fewer of those, we could perhaps use that as a lookup for the 5156 events. This may also be able to be done as a subsearch (not sure which would be best yet). What is the time frame you are looking at? Specifically, how much lag could we before you get the information? Would a minute or 5 minutes be too much lag because you are trying for sub-minute alerts, or would a minute or a few minutes be OK?
So I'd like to ask if answer A or B would work? Though honestly option D sounds pretty interesting and I think it would be useful for my own uses too...