sysmon props.conf _time extractions is working but isn't adding the milliseconds that it should from the UTCTime value.

[jlstanley]

My props.conf time extraction looks like this and works great for extracting the time and milliseconds from the tool to get data in in splunk.
Added it for both Xml source and WinEventLog.

[XmlWinEventLog:Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=

MAX_TIMESTAMP_LOOKAHEAD=23
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3Q

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=
MAX_TIMESTAMP_LOOKAHEAD=23
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3Q

[jlstanley]

for some reason my paste of the props from before was missing the timestamp prefix:
```
[XmlWinEventLog:Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=
```

[mstjohn_splunk]

Hi @jlstanley,

Sorry you haven't received any answers to your question. I'm sure help is on the way!

But, in the mean time,If you want to try to get some immediate help for your question, you should join the 5000+ Splunk users in our public Slack Community chat. People ask each other for immediate help on there daily. You can share your question/link to your post there to see if anyone can take a stab at it.

You first have to request access through https://splk.it/slack Fill out the form, and once you receive the approval email from our Community Manager (usually the approval process may take a couple days), you can access Slack.com and ask for help in the #general channel.

[adonio]

try this time format for milliseconds %<int>N
read here:
http://docs.splunk.com/Documentation/SplunkCloud/latest/SearchReference/Commontimeformatvariables
your case:

   [WinEventLog://Microsoft-Windows-Sysmon/Operational]
    SHOULD_LINEMERGE=false
    NO_BINARY_CHECK=true
    BREAK_ONLY_BEFORE=
    MAX_TIMESTAMP_LOOKAHEAD=23
    TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3N

[jlstanley]

thanks @adonio. I tried that but same result. I made the changes on both the deployments server so the uf will get updated as well as the indexers.

[XmlWinEventLog:Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=<Event xmlns=
TZ=UTC
TIME_PREFIX=<Data Name=\'UtcTime\'>
MAX_TIMESTAMP_LOOKAHEAD=23
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3N

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
BREAK_ONLY_BEFORE=<Event xmlns=
TZ=UTC
TIME_PREFIX=<Data Name=\'UtcTime\'>
MAX_TIMESTAMP_LOOKAHEAD=23
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3N

[adonio]

i don t have sysmon installed, can you verify its indeed writes milliseconds?
i looked at the TA (which is pretty new) as well at the blog and one very nice .conf presentation. could not see milliseconds in the events as presented
https://splunkbase.splunk.com/app/1914/#/overview
https://conf.splunk.com/files/2017/slides/effectively-enhancing-our-soc-with-sysmon-powershell-loggi...
https://www.splunk.com/blog/2014/11/24/monitoring-network-traffic-with-sysmon-and-splunk.html
on the other hand, it seems like there are miliseconds in the event sample in microsoft documentation:
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

ill suggest to try to remove all your props.conf and use only inputs.conf

 [WinEventLog://Microsoft-Windows-Sysmon/Operational]
    disabled = false
    renderXml = 1

play with the renderXml

[jlstanley]

Well this is in each event as a field so I'm targeting it as the time
2018-08-29 14:40:40.002

There is nothing in the default/props.conf that would do the date/time extraction and I wouldn't expect the splunk will do it automatically with the date/time that far into the event and the fact that it's an add on that is not from them, even if it's xml. I'm hoping someone answers this question that is running sysmon successfully so I can find out for sure if it should work. I appreciate the help though.