cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted

Office365 - Random Possible Time Mismatch

Jump to solution

For a while now our team has been receiving events from our Office365 data source and occasionally would receive random alerts about a possible time mismatch coming from the data source despite having several logs. Because of it's random nature, it's a bit hard to track down exactly why this is occurring. Has anyone found the root cause for this behavior? I'd like to discontinue it so our team knows when there is an actual problem with the device instead of receiving a handful of alerts a day and ignoring them.

Labels (2)
1 Solution

Accepted Solutions
Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Office365 - Random Possible Time Mismatch

Jump to solution

It's a bit difficult to provide a general cause for this other than the obvious - there's a mismatch between the time in the events and the time on the receiver and it's outside the expected values for the datasource.

Typical reasons are systems with incorrect clocks, systems that are disconnected from the network for extended periods of time, initial messages from newly built VMs before they've picked up a time server, parsing errors, incorrectly selected timezone in the datasource configuration (where this is an option).

It's much easier to analyse this in a specific form - i.e. when a sample event is identified.  Unfortunately at the moment this requires querying the receiver database as there's no other way of consistently identifying these.  Within the receiver database, last_time represents the time we parsed the event as occurring at, event_time is the time the event was received:

A good example query would be:
nquery -d rec -q "select IPSID, objectid, event_time, first_time, last_time, TIMESTAMPDIFF(MINUTE, event_time, last_time) as timediff, data_source, sig_id from event Where event_time > '06/12/2020 12:00:00' and ipsid=144142679507206144  order by timediff desc limit 10"

Even with a relatively good query (please use the event_time to try to limit this to the smallest set you can) this can take 30+ minutes to complete.  You can get the ipsid value from a datasource export from the receiver - it is the long 18 digit id number which uniquely identifies a datasource within your SIEM environment.

Once you have identified the event with the issue, you can get the raw packet from the packet table on the receiver for analysis - use the objectid from the output of the previous query to run something similar to this:
nquery -d rec -q 'select * from packet where objectid=9223372036938766227' --noblob --long

View solution in original post

5 Replies
Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Office365 - Random Possible Time Mismatch

Jump to solution

It's a bit difficult to provide a general cause for this other than the obvious - there's a mismatch between the time in the events and the time on the receiver and it's outside the expected values for the datasource.

Typical reasons are systems with incorrect clocks, systems that are disconnected from the network for extended periods of time, initial messages from newly built VMs before they've picked up a time server, parsing errors, incorrectly selected timezone in the datasource configuration (where this is an option).

It's much easier to analyse this in a specific form - i.e. when a sample event is identified.  Unfortunately at the moment this requires querying the receiver database as there's no other way of consistently identifying these.  Within the receiver database, last_time represents the time we parsed the event as occurring at, event_time is the time the event was received:

A good example query would be:
nquery -d rec -q "select IPSID, objectid, event_time, first_time, last_time, TIMESTAMPDIFF(MINUTE, event_time, last_time) as timediff, data_source, sig_id from event Where event_time > '06/12/2020 12:00:00' and ipsid=144142679507206144  order by timediff desc limit 10"

Even with a relatively good query (please use the event_time to try to limit this to the smallest set you can) this can take 30+ minutes to complete.  You can get the ipsid value from a datasource export from the receiver - it is the long 18 digit id number which uniquely identifies a datasource within your SIEM environment.

Once you have identified the event with the issue, you can get the raw packet from the packet table on the receiver for analysis - use the objectid from the output of the previous query to run something similar to this:
nquery -d rec -q 'select * from packet where objectid=9223372036938766227' --noblob --long

View solution in original post

Highlighted

Re: Office365 - Random Possible Time Mismatch

Jump to solution

This was incredibly helpful. I have been looking and asking resources for what seems to be over a year or so attempting to correct this. I ended up running a TQ query to get the ipsid since Excel kept cutting off part of the ID but i was able to locate what I believe is the issue. Running the query and pulling the blob down as suggested, I found random events coming in which were about 7 days old. I'll provide examples of my findings (sensitive/company pertinent data redacted of course).

144130589056827392|6014727866|06/12/2020 03:34:49.000|06/05/2020 13:58:41.000|06/05/2020 13:58:43.000|9456|586|2330191503


Reading through the raw packet the SIEM received; I found reiterations where the creation of the packet was on June 5th, but the received time was earlier today as mentioned before. 

packet.packetdata : {"CreationTime":"2020-06-05T13:58:43"

packet.timestampsec: 06/12/2020 03:34:49.000

My question now is, how do I correct this issue? The SIEM is configured to not accept data older than a day, which it shouldn't in my opinion - but this isn't a simple case of a reconfigured data source with a bad timezone. Being that this is API dependent, is it recommended to have McAfee Support investigate the issue? Or is this a Microsoft issue since it's their API call?

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 6

Re: Office365 - Random Possible Time Mismatch

Jump to solution

It's a combined investigation - the issue could be caused by the McAfee parsing, by Microsoft or by a configuration on one of your systems.  If you could genericise the event that would be very helpful in analysing it.

e.g. we don't need any unique IDs other than to know they're different so "filename" "filepath" "uuid" "ipofsource" "ipofserver" etc... would do, however all of the time fields and their contents will be essential.

The signature id according to my system is "SharePoint Accessed file" 

"Creation Time" looks like it comes from the packet itself and logically I would assume this to be the creation time of the file, which does not make sense as the parsed last_time value of the event.  I would expect us to use "accessed time" instead (if such a thing exists in the packet).

Highlighted

Re: Office365 - Random Possible Time Mismatch

Jump to solution

Thank you for the help so far. I've pulled down the event again to scrub it. Would it be preferred to open a ticket at this point with the information gathered and reference this forum? If not, I can paste a scrubbed version of the event to this redacting only pertinent customer information.

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 6

Re: Office365 - Random Possible Time Mismatch

Jump to solution

A ticket would be the best place to ensure this gets the appropriate focus applied to it to get it resolved.

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community