Time sync generates ‘Possible CVE’ entry in System event log – bug?

Topic

New Reply

I first noticed this when I was testing PowerShell queries on a test laptop running Windows 1809. I noticed something worrying in the System log. Here’s the query:

Get-EventLog -LogName System -Newest 20 | Format-Table

I’ve highlighted the results which caught my eye:

I changed the query to use Format-List so I could see the name of the Source and saw that it was Microsoft-Windows-Kernel-General.

I rewrote the query to narrow it down:

Get-EventLog -LogName System -InstanceId 1 -Source Microsoft-Windows-Kernel-General -Newest 20 | Format-Table

This showed that the Possible detection of CVE event was logged once a day at least, sometimes twice or three times.

The message included:

This Event is generated when an attempt to exploit a known vulnerability (2022-12-29T19:38:59.190732800Z) is detected.
This Event is raised by a User mode process.

This sounded worrying, especially as the last sentence indicated that something I was doing (as the only user) was responsible for triggering the event.

However, there were anomalies. For example, one event was logged on December 25th when I was many miles away visiting my daughter for Xmas dinner. Others were at times when I had been asleep.

Yet another anomaly was that there was no record found of the CVE vulnerability mentioned (2022-12-29T19) in the CVE Details security vulnerability database.

Another puzzling thing was I couldn’t find these Possible detection of CVE events in either the built-in Event Viewer or Nir Sofer’s FullEventLogView. They’re just not visible… at all.

I’ve finally got round to testing on another laptop. This had Windows 22H2 clean installed on Nov. 1st and was then shut down and put to one side immediately after Windows Update had shown there were no more updates at the time to be found. I’ve just powered it up and run the same PowerShell query:

Yet I haven’t used it for *anything* and there’s only Windows installed; no other software. It’s *only* internet access has been to Windows Update. I haven’t even opened Edge on it. I went back to the System logs again and finally realised what was happening.

Every Possible detection of CVE event has a corresponding Time Sync event when Windows compares itself with time.windows.com and makes any necessary adjustment. Every. Single. Time. It’s not a User mode process causing it at all, it’s an automatic system event that is the culprit.

IMO it’s simply a bug in whatever interaction there is between the system’s automatic time sync and PowerShell.

Try the second PowerShell query for yourself and see if your results are the same…

Hope this helps…

1 user thanked author for this post.

PKCano

Reply | Quote

Replies

(2022-12-29T19)  I think that’s a date.  I think it’s saying possible detection of CVE with no details of what CVE.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

What’s the exact event log that is throwing that off?

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

EventLog – Possible Detection of CVE – Microsoft Community

I think I agree with poster number 2.  Powershell is posting a bogus message.  Let me run this by some gurus.

 

Also discussed here:  event log – Alert ” Possible detection of CVE” – Super User

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

satrow

Reply | Quote

Susan Bradley wrote:

What’s the exact event log that is throwing that off?

Example:

Index : 200939
EntryType : Information
InstanceId : 1
Message : Possible detection of CVE: 2022-12-29T19:38:59.190732800Z
Additional Information: 2022-12-29T19:38:59.190165900Z

This Event is generated when an attempt to exploit a known vulnerability (2022-12-29T19:38:59.190732800Z) is detected.
This Event is raised by a User mode process.

Category : (5)
CategoryNumber : 5
ReplacementStrings : {2022-12-29T19:38:59.190732800Z, 2022-12-29T19:38:59.190165900Z, 1, \Device\HarddiskVolume2\Windows\System32\svchost.exe…}
Source : Microsoft-Windows-Kernel-General
TimeGenerated : 29/12/2022 19:38:59
TimeWritten : 29/12/2022 19:38:59
UserName : NT AUTHORITY\LOCAL SERVICE

1 user thanked author for this post.

PKCano

Reply | Quote

As a test I did this:

1. Cleared the PowerShell console.
2. Ran the query.
3. Started the w32time service.
4. Forced a manual time sync.
5. Ran the query again.

This showed another Possible detection of CVE event added to the table.

As the w32time service was still running I next did this and took a screenshot:

1. Cleared the PowerShell console.
2. Ran the query.
3. Forced a manual time sync.
4. Ran the query again.

I’ve done this several times now and each time another Possible detection of CVE event is added to the table.

IMO this shows a reproducible link between a time sync and the recording of a new CVE event.

I ran another query:

Get-EventLog -LogName System -Newest 10 | Format-Table

I’m not seeing any associated Event 24 Category 11 event mentioned in the cited SuperUser post.

The cited answers.microsoft.com post was interesting. I ran the query from it:

Get-EventLog system -source Microsoft-Windows-Kernel-General -InstanceId 1  | measure

This generated a count of 1184 events on my Windows 10 1809 test laptop.

2 users thanked author for this post.

PKCano, satrow

Reply | Quote

Rick,

I ran your 2nd Powershell command on my own system, Win10 Pro (build 22H219045.2364),  and it didn’t return any results at all!

So I then ran your 1st Powershell command and, while it did return some results, there were no references to that CVE (nor any other.)

Just FYI…

Since Windows 95, all my Windows OS’s have always been set to sync their time with an official NIST time server, not Window’s “default” time.windows.com server, and, because I’m not seeing any CVE alerts, I “suspect” the problem could be the NTP (Network Time Protocol) request packets being sent back-and-forth between your PC and Microsoft’s time server aren’t properly encrypted.

I’ve always use the NIST servers because, being retired military, I know they’re always accurate, “right down to the millisecond“, whereas the time on a privately owned time server, such as Microsoft’s time.windows.com, can “drift” away from the correct time by as much as 5 secs one way or the other.

I know 5 secs isn’t really that big a deal for most people, but I’m a sticker for being extremely accurate when it come to this because I know, if the time stamp on my PC is off – even by a few milliseconds, it can cause problems with the data packets it sends/receives over the internet.

You can blame that on the special “Wide Area Networks” training I received at Wright-Patt AFB back in 1990 (it was still called ARPANET back then.)

I’m currently using the time-b-nist.gov server because it’s one of the 4 NIST time servers that only supports NTP requests that use authenticated symmetric key encryption – which means it isn’t susceptible to being hacked!

Full list of all the NIST time servers

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Just another Forum Poster wrote:

I ran your 2nd Powershell command on my own system, Win10 Pro (build 22H219045.2364), and it didn’t return any results at all!

An interesting post… thank you for taking the time to both run the queries and for the very interesting hypothesis about unencrypted NTP packets. I’m off to test that by switching time sources.

I was also very interested in the info about time drift on public time servers. Perhaps my internal CR2032 battery isn’t dying after all!

Reply | Quote

Hmm… here in the UK I haven’t yet been able to find the equivalent to NIST… so I thought I would use pool.ntp.org as a starting point as an alternative time source.

Although I’m going to use my Windows 10 Pro 1809 laptop primarily for testing (‘cos I don’t care about it and it’s *long* overdue for wiping and clean installing), I thought I would save the current time server information… so I fired up Nir Sofir’s RegScanner and told it to look for time.windows.com:

Three results show what I was expecting… the OS’ original installation timestamp… ‘cos I’ve never made any changes. Two, however, showed a name that I’ve added to my ‘need to Google up on’ list:

However, I’ve been distracted by the thought ‘How soon are these Potential CVE events likely to appear.

So, I’ve wiped a MCT-installer USB for Windows 10 2004 and re-used it to create a new MCT-installer USB. I used my Detect ISO version.ahk script to look at its properties and it shows this:

This suggests there have been no changes to the downloadable ISO since September 2022, even though it was used to create an installer USB today.

Reply | Quote

Those “SpecialPoolTimeRemaining” entries contain a special code used by the Windows Time server (W32time.dll) when it connects to your select NTP server.

I checked, and on my system, they both start with time-b.nist.gov followed by a hex value. So your result is exactly what I’d expected for someone still using time.windows.com.

As for the UK equivalent of NIST, it appears to be NPL (National Physical Laboratory) and, according to info I found on the web, they operate two “official” NTP servers available for time sync.

ntp1.npl.co.uk and ntp2.npl.co.uk

BTW, just like NIST here in the US (where their NTP servers get their time from a “cesium fountain atomic clock” located at NIST laboratories in Boulder CO), the NPL NTP servers also get their time from a “cesium fountain atomic clock” located at NPL Bushy Park, Teddington, Middlesex.)

However, the UK gets bragging rights because the first cesium clock was developed and built by Louis Essen at NPL back in 1955!

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Just another Forum Poster wrote:

As for the UK equivalent of NIST, it appears to be NPL

Thank you for the information about NPL.

I’m happy to take this for a dance. IMO the steps are:

1. Create new MCT USB installer based on latest available MS download. [Done]
2. Clean install test laptop offline; halt at OOBE. [Done]
3. In Audit mode, run PS query against System log; screenshot baseline results.
4. Start w32time service, if not already started.
5. Connect to Internet.
6. Force-update time sync.
7. Run PS query against System log; screenshot results.
8. Run w32time command to change time servers from time.windows.com to ntp1.npl.co.uk and ntp2.npl.co.uk.
9. Force-update time sync.
10. Run PS query against System log; screenshot results.

Have I missed anything glaringly obvious?

PS: At Step 2 I noticed the latest MCT installer shows ‘Last updated June 2021’… so I assume that refers to ‘licensing terms’.

Reply | Quote

OK… I’m going to stop right here at step 3:

1. Create new MCT USB installer based on latest available MS download. [Done]
2. Clean install test laptop offline; halt at OOBE. [Done]
3. In Audit mode, run PS query against System log; screenshot baseline results.

This is an absolutely clean install – all partitions wiped – and yet even in Audit mode and before *any* connection to the internet for an initial time sync my first 2 PowerShell queries show this:

Tell me that’s not a bug…

Reply | Quote

Several of which do not seem to be working at present 5:30 PM ish eastern time. Maybe lots of traffic b4 new years??
BTW I do not recall if they respond to a ping???

🍻

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

wavy wrote:

BTW I do not recall if they respond to a ping???

Nope!

Time servers will only respond to a proper NTP request.

1 user thanked author for this post.

wavy

Reply | Quote

wavy wrote:

Several of which do not seem to be working at present 5:30 PM ish eastern time. Maybe lots of traffic b4 new years?? BTW I do not recall if they respond to a ping???

I’m not sure what you’re referring to, @wavy.

AFAIK the default windows time source – time.windows.com – is not a single time server (eek!) but, instead, a distributed public NTP resource so the endpoint depends on the geographical region where you live.

For example, if I ‘ping’ the address for time.windows.com, I usually get a response from a Microsoft server in Ireland… but today I get a hit from Cardiff in Wales. That’s a new one on me… new datacentre?

If you’re Satya Nadella and think of all the millions of Windows clients all trying to sync to/from time.windows.com as a default time source… how confident are you that there’s not going to be hiccups?

Hope this helps…

1 user thanked author for this post.

wavy

Reply | Quote

Rick Corbett wrote:

As for the UK equivalent of NIST, it appears to be NPL (National Physical Laboratory) and, according to info I found on the web, they operate two “official” NTP servers available for time sync. ntp1.npl.co.uk and ntp2.npl.co.uk

Whilst this issue I flagged appears to be a long-standing bug in Windows, I’m intrigued… so intend to follow up these alternative time sources for comparison.

Reply | Quote

Rick Corbett wrote:

Whilst this issue I flagged appears to be a long-standing bug in Windows

If that’s true, then why am I not getting any Possible detection of CVE events.

I think we need a much larger sample size as to who’s system is and isn’t seeing this before we can reach any conclusion about what’s causing it and whether it’s a bug or not.

Reply | Quote

[Bob99]

Although I have the Windows time service disabled, as I use another program for my time synch that I’ve been using since the days of Win98, I was somewhat surprised to find that I have some entries in response to the second PowerShell command of your initial post! This further illustrates the concept of this being a, by now, potentially very old bug within windows. These entries seem to correspond to the actual time of day that I have started my computer from being completely shut off, no hibernation or standby of any kind. After further review, apparently there are also entries from times that I’ve launched Dimension 4 to synch the time on my computer to a pre-selected server, in addition to times that I’ve started my computer.

I use Dimension4 for my timekeeping/synch needs, as I have been since when I was running Windows 98 and 98SE. The program works well, even under the purview of Windows 10. Because of this, I’ve disabled the Windows settings for it to check the time on its own everywhere I’ve found them within Win7 and, now, Win 10. The startup type for Windows Time service is “Disabled”, and has been from the word “Go”.

BTW, I’ve always used the NIST servers at Boulder/Ft. Collins for years with no issues, but I’ve never been privy to being approved to use the “b” server as you have, @alejr!  😉

EDIT: In looking into my registry courtesy of Rick’s screenshot in post 2513221, I have found that on both of my machines, I don’t have any data in the field of “SpecialPollTimeRemaining”. The field is there, but the actual data filed is blank. That goes for both places with that data field on both computers.

Things that make you go “Hmmmm”.

• This reply was modified 8 months, 4 weeks ago by Bob99.
• This reply was modified 8 months, 4 weeks ago by Bob99. Reason: Modified info in 1st. paragraph

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Bob99 wrote:

BTW, I’ve always used the NIST servers at Boulder/Ft. Collins for years with no issues, but I’ve never been privy to being approved to use the “b” server as you have, @alejr!

No “special” approval required, I simply manually entered it as my preferred time server in the “Internet Time Settings” tab for Windows and it works.

The four “Authenticated service” time servers at NIST only respond to NTP requests from users who are registered with NIST and use the special encryption key they were issued.

If your Dimension4 S/W doesn’t include those four servers in its list of available time servers, that simply means they never bothered to register with NIST to obtain the encryption key required to use them while Microsoft did for their Windows OS’s.

Reply | Quote

Alejr May I ask what was that url that you use as a server?

🍻

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

Just another Forum Poster wrote:

If that’s true, then why am I not getting any Possible detection of CVE events.

Good point, well made.

I’ve only seen this on two devices, both configured from clean install by me, albeit years apart… although Susan’s citations suggest I’m not alone in what I’ve seen.

However, a default installation of Windows points to time.windows.com as its default time source… so at some point I assume you changed this default?

Reply | Quote

Bob99 wrote:

Although I have the Windows time service disabled, as I use another program for my time synch that I’ve been using since the days of Win98, I was somewhat surprised to find that I have some entries in response to the second PowerShell command of your initial post! This further illustrates the concept of this being a, by now, potentially very old bug within windows.

Thank you, @bob99, for your additional information.

I didn’t even get as far as checking that the w32time service was even running before I ran my first two queries.

In hindsight that was wrong of me… but I’ve been guessing each step of the way.

Can you please post a screenshot or text output of the entries in response to the second PowerShell command in my initial post?

My gut feeling is that there’s a fundamental issue here… but I’m not smart enough to work out what the anomalies mean.

Reply | Quote

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\WINDOWS\system32> Get-EventLog -LogName System -InstanceId 1 -Source Microsoft-Windows-Kernel-General -Newest 20 | Format-Table

Index Time          EntryType   Source                 InstanceID Message
—– —-          ———   ——                 ———- ——-
74867 Dec 31 11:31  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-31T19:31:42.6970000Z…
74793 Dec 30 11:05  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-30T19:05:38.1380000Z…
74703 Dec 29 10:51  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-29T18:51:25.1190000Z…
74632 Dec 28 11:45  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-28T19:45:08.4120000Z…
74492 Dec 28 11:15  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-28T19:15:08.1400000Z…
74425 Dec 27 17:10  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-28T01:10:36.1550000Z…
74366 Dec 27 16:25  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-28T00:25:09.0540000Z…
74301 Dec 27 15:55  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T23:55:08.7320000Z…
74230 Dec 27 15:25  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T23:25:09.0420000Z…
74166 Dec 27 14:26  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T22:26:32.7150000Z…
74097 Dec 27 13:56  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T21:56:33.5020000Z…
73857 Dec 27 13:26  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T21:26:33.6110000Z…
73721 Dec 27 12:56  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T20:56:32.9170000Z…
73627 Dec 27 12:26  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T20:26:33.2540000Z…
73541 Dec 27 10:36  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-27T18:36:19.5650000Z…
73469 Dec 26 11:20  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-26T19:20:08.1030000Z…
73385 Dec 25 12:03  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-25T20:03:25.6390000Z…
73296 Dec 24 11:39  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-24T19:39:53.1600000Z…
73221 Dec 23 10:59  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-23T18:59:48.4600000Z…
73144 Dec 22 12:15  Information Microsoft-Windows…            1 Possible detection of CVE: 2022-12-22T20:15:09.2490000Z…

PS C:\WINDOWS\system32>

Since I couldn’t get a screenshot to go, the above is a copy/paste of the entire screen contents instead. FWIW, I’m running PS 5.1 that came with Win10.

I hope this helps your “chase down the rabbit hole”!

2 users thanked author for this post.

wavy, Rick Corbett

Reply | Quote

Bob99 wrote:

Since I couldn’t get a screenshot to go, the above is a copy/paste of the entire screen contents instead. FWIW, I’m running PS 5.1 that came with Win10. I hope this helps your “chase down the rabbit hole”!

Thank you!

Now I know that I’m not imagining it from the two devices that I configured and have subsequently been monitoring for this [issue].

I’m going to assume that you never changed the default time server source? (which many people would just say ‘duh!’ to). Please correct me if I’m wrong.

However, I note from an earlier post of yours that you have the Windows Time service disabled, yet still your event logs show this issue.

Given my own testing, I don’t believe this is an issue with the Windows Time service per se but merely how PowerShell misinterprets the results of not being able to access data that it’s expecting. However, this is just a guess.

Hope this helps…

Reply | Quote

Rick Corbett wrote:

However, I note from an earlier post of yours that you have the Windows Time service disabled, yet still your event logs show this issue.

The reason for the entries, I believe, is that Dimension4 runs as a service in any edition of Windows beyond XP, per their documentation. So, it has a service that it installs and that service’s startup type is set to “Automatic”.

So, my guess is that it starts when the computer is started and checks and adjusts the time in the background, after which the service then stops, pending any requests from the user launching the program itself, which requires the service to be running in order for the executable to fully function.

I’m not a bit worried about this bug, but I do find it quite interesting. If you need any additional info, don’t hesitate to ask, as I’m more than happy to help you gather any additional data!

Reply | Quote

[Bob99]

Rick-

I have just confirmed that the entries directly correspond to the changing or attempted changing of the system time by my authorized application, Dimension4!

I went into my Event Log and looked for entries corresponding to the first entry in my post above that is from today at 12:31:42.6970000, and found two entries: The first one in the Security part of the log indicating a successful audit for a “Security State Change” that corresponded to a change of the system time, Event ID 4616; and the second one in the System area of the event log, listed as “Kernel-General” with Event ID of 1 and a task category of 5. The description mentions that the reason for this entry is a system time change and it details the exact change itself from one very precise time to another very precise time, and also mentions the exact process that changed it, Dimension4.

EDIT: One additional note…I have two systems, both of which are running Windows 10 22H2 x64 Pro, and both are currently on build 19045.2364. This is where I have obtained the data presented.

• This reply was modified 8 months, 4 weeks ago by Bob99.

1 user thanked author for this post.

Rick Corbett

Reply | Quote

@Rick-Corbett and @alejr ( @bigal67 ) –

Could it be that when PowerShell was first being developed, that there was a prevalent piece of crapware circulating that was disguised as a system time modification utility, thereby making Powershell think that it may have encountered a vulnerability due to the change in a system’s time?

Reply | Quote

Bob99 wrote:

have just confirmed that the entries directly correspond to the changing or attempted changing of the system time by my authorized application, Dimension4!

Thank you, @bob99, for following up on this. Any chance you can run another PowerShell query to  check what your system’s current timeserver is and post the results (screenshot or txt output)?

w32tm /query /status

Hope this helps…

 

Reply | Quote

[Bob99]

Here you go! :

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\WINDOWS\system32> w32tm /query /status
The following error occurred: The service has not been started. (0x80070426)
PS C:\WINDOWS\system32>

EDIT: Since the above results were with the Dimension4 service stopped, I tried the same query with the Dimension4 service running by itself, and with the Dimension4 service running along with the actual program, D4.exe. Both ways resulted in the same result as above from the query. To me, this shows that Dimension4 doesn’t leverage the Windows time service in any way, shape or form.

• This reply was modified 8 months, 4 weeks ago by Bob99.

Reply | Quote

Bob99 wrote:

Could it be that when PowerShell was first being developed, that there was a prevalent piece of crapware circulating that was disguised ad a system time modification utility, thereby making Powershell think that it may have encountered a vulnerability due to the change in a system’s time?

I’m hopeful that perhaps @sb’s ‘gurus’ may help shed a little light on this.

Reply | Quote

Bob99 wrote:

The following error occurred: The service has not been started. (0x80070426)

My apologies. I should have asked you to first make sure that the w32time service was running using the following command:

net start w32time

Normally I would then use:

W32tm /resync /force

However, I have no experience of Dimension4 nor whether it surpresses calls to the built-in time service.

Reply | Quote

Anyone out there that uses the default Windows time service and is willing to run a couple of PowerShell commands step-by-step to report on (but not change) possible entries to a standard Windows log?

 

Reply | Quote

I can fire up a box with standard time for a trial. What do you want me to do?

cheers, Paul

Reply | Quote

Paul T wrote:

I can fire up a box with standard time for a trial. What do you want me to do?

My thanks, Paul, for the offer. Perhaps in an elevated PowerShell console use the following to see if there’s an issue:

Get-EventLog System -Source Microsoft-Windows-Kernel-General -InstanceId 1 | measure

I’m not at all sure how VM’s will react (which is the main reason why I’ve stopped using them except for simple testing of registry key edits) but, if you do get a result then please next run:

Get-EventLog -LogName System -InstanceId 1 -Source Microsoft-Windows-Kernel-General -Newest 10 | Format-Table

… and post a screenshot; or:

Get-EventLog -LogName System -InstanceId 1 -Source Microsoft-Windows-Kernel-General -Newest 20 | Format-List > $env:SystemDrive\cve.log

… to pipe the results to a cve.log file in the OS’ root folder (usually C:\)

 

Reply | Quote

Rick, could the entry be triggered by the 158 VMICTimeProvider ‘error’ message?

If so, what’s the source for that and how should it be corrected to prevent triggering this rather worrying log entry?

Reply | Quote

satrow wrote:

Rick, could the entry be triggered by the 158 VMICTimeProvider ‘error’ message? If so, what’s the source for that and how should it be corrected to prevent triggering this rather worrying log entry?

That is a very good question, my friend, and I now need to explore that further. Thank you for pointing this out.

The two laptops I used for testing are identical Dell Latitude E7450‘s apart from OS build… and both have vPro technology built-in to their CPUs. However, I took into consideration the statement:

This behavior is expected for VMICTimeProvider on non-HyperV-guest environments.

Whilst the hardware supports hypervisors, I’ve never used either HyperV nor any other third-party hypervisors on them.

However, it’s not beyond the bounds of possibility that this may be a factor.

@Bob99 – You posted a reply that you see the same response. Was this on a device with vPro technology? Make/Model would be appreciated.

Reply | Quote

Rick Corbett wrote:

@Bob99 – You posted a reply that you see the same response. Was this on a device with vPro technology? Make/Model would be appreciated.

No, both of my units are plain ol’ desktops. Both have a motherboard that has an Intel B365 chipset. The only core difference between them is the CPU…one has an i5-9500, and the other has an i3-9100.

So, neither has any vPro features as far as I know.

BTW, if you’d like, I can enable the Windows time service and see what I get for a response from your latest PowerShell query from last night.

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Rick Corbett wrote:

I’m not sure what you’re referring to, @wavy.

Well yesterday none of the time servers time.nist.gov or windows time server for instance would ‘update’. I have them working today, but none of them respond to a ping, all time out repeatedly. The ntp-b.nist.gov does not update for me.

🍻

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

wavy wrote:

but none of them respond to a ping

As I pointed out above, timer server’s don’t respond to ping requests. They only respond to a properly formatted NTP request!

Reply | Quote

I get the same error message (using the power shell command above).

What is interesting is that I use a small utility (neutron.exe) to 1- get the time from “time-a.nist.gov” and 2- store the time in the system. When I just get the time, no error message is recorded. It is only when I store the time (synchronize) that I get 2 identical CVE error messages as Rick reported.

I hope this adds some useful information to this discussion.

Reply | Quote

JC Zorkoff wrote:

I hope this adds some useful information to this discussion.

Yes it does. Thank you.

It confirms that this is a potentially unrecognised issue that points to what is usually referred to as a ‘false positive’ which has, up until now, remained hidden and is now being queried.

However, what triggers it is still a mystery at the moment.

Reply | Quote

And I bet that if you were to look in @JC-Zorkoff ‘s machine, you’d find nearly identical entries in the Event Log to the ones I found on my machines for the times that the machine’s system time was changed. The only difference in the entries would most likely be the name of the application/process/executable that changed the system’s time, D4.exe for my machines and neutron.exe for @JC-Zorkoff ‘s machine.

However, what triggers it is still a mystery at the moment.

I’m going to go out on a bit of a limb here and make a guess based upon the input of @JC-Zorkoff and my own findings that I got with your help, Rick.

I believe the trigger is the actual act of changing the system’s time and that for some reason, PowerShell just doesn’t know how to deal with the actual data generated by that act, no matter the source of the act, Windows’ own time service or another app/process/executable outside of Windows’ built-in stuff.

I’m hoping that Susan gets some kind of word by the end of this week. 🤞

1 user thanked author for this post.

Rick Corbett

Reply | Quote

@bob99.. I can’t dispute your well-argued logic. Thank you.

Reply | Quote

What I don’t understand is why this Potential CVE error (false positive or not) has not been picked up and dealt with before now (since Windows v1809 at least) by the telemetry submissions of millions of Windows 10 PCs.

Does this suggest that it’s actually a minor issue or one that ‘phone home‘ doesn’t actually report on?

I’m hoping that @Susan’s contacts within Microsoft can shed a little light on this conundrum.

Reply | Quote

I may have to take this more social – or wait until after the holidays.

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Susan Bradley wrote:

I may have to take this more social – or wait until after the holidays.

Thank you, Susan.

Reply | Quote

Bob99 wrote:

So, neither has any vPro features as far as I know.

Many thanks for your response. I’m going to rule out vPro technology as irrelevant… so far.

Reply | Quote

[Bob99]

Rick Corbett wrote:

I’m going to rule out vPro technology as irrelevant… so far.

Key point…”so far”. I just got off Intel’s ARK pages that have in depth specs for their chipsets and CPUs, and I found out that my 9500 chip is listed as eligible for the Intel vPro Platform.

As you can see from the image above, the processor is eligible, but there are a bunch of disclaimers at the bottom of the page so nobody holds Intel’s feet to the proverbial fire with regards to that qualification.

The same source said nothing about vPro in the specs for my i3-9100 CPU in my other machine, so I presume it isn’t capable of it.

EDIT: I just looked up my chipset (365) and the specs for it say NOTHING about vPro.

• This reply was modified 8 months, 3 weeks ago by Bob99.

Reply | Quote

Bob99 wrote:

I believe the trigger is the actual act of changing the system’s time and that for some reason, PowerShell just doesn’t know how to deal with the actual data generated by that act, no matter the source of the act, Windows’ own time service or another app/process/executable outside of Windows’ built-in stuff.

I think that you’ve nailed it. Bravo!

Still a bug, IMO.

If there’s a bug bounty then, IMO, it should be awarded to this AskWoody forum to fund costs… due to group effort… or to @Bob99 for his analytical skills.

You folks are amazing…

2 users thanked author for this post.

wavy, Bob99

Reply | Quote

Wow… you’re just like a hounddog. I’ve posted this ‘cos you may well end up with the ‘sorted’ award. Thank you so much for taking such an interest in what was once an anomaly.

1 user thanked author for this post.

Bob99

Reply | Quote

Thanks for the plaudit (I think?). 😉

I’m still hoping we hear from Susan to see what she finds out later this week. Let’s see how close we did or didn’t come! After all, @satrow may have been on to something as well!

I believe that, although this may seem as a minor bug it nevertheless deserves attention from MS, especially since it may be present in the newer versions of PowerShell, such as 7.3.

I hate the idea of someone thinking they’ve been hit with a piece of crapware due to seeing the message that you saw in PowerShell, (when, in fact, they haven’t) and subsequently taking it for action when there’s no action to take.

Reply | Quote

Bob99 wrote:

I’m still hoping we hear from Susan to see what she finds out later

Me too. I think that we’ve taken this as far as we’re able too… for the moment

Reply | Quote

@Rick-Corbett –

There’s only one data point I can think of that we don’t currently have… the version of PowerShell that you have been using for your troubleshooting of this issue and the version of PowerShell that @alejr used.

Remember, @alejr DIDN’T get any results showing a potential CVE issue when he tried your second command that isolated results to just the Windows kernel, per his post here.

So, @alejr ( @bigal67 ), just which version of PowerShell did you use to see if you got results similar to Rick’s??

My own results are from version 5.1, which comes with Windows 10 by default.

Reply | Quote

Bob99 wrote:

So, @alejr ( @bigal67 ), just which version of PowerShell did you use to see if you got results similar to Rick’s??

Mine’s the default version included in Win10 Pro 22H2 which is also 5.1

However, since the last part of the version info, .2364 matches the new Windows version info displayed after installing the Dec update, it appears it does get updated at least somewhat regularly so mine “may” be more up-to-date.

1 user thanked author for this post.

Bob99

Reply | Quote

Mine says the same thing as yours, .2364. I just wasn’t sure that anything beyond the basic #.# would really make a difference.

Since I’ve found out that the newer version of PS can be installed “alongside” 5.1, I may try doing just that (using the .msi installer, NOT the Store version), and see just what happens with Rick’s queries.

Reply | Quote

When I stopped my clean install of Windows 10 Pro 22H2 during OOBE, my laptop displayed Possible detection of CVE before ever connecting to the internet (for a time sync or any other purpose). I shut it down at that point.

I’ve just fired it up again to check the PowerShell version:

i think my next steps are to complete OOBE, let Windows Update do its thing until there’s no more updates available then run the PowerShell query against the System event log.

This should show whether a slight incremental point version update to PowerShell produces different results.

Reply | Quote

Update:

1. I completed OOBE, ran Windows Update (and multiple reboots… yada, yada, yada) until no more updates were to be found (a).

2. I checked the PowerShell version and confirmed it has received a minor incremental update to the build version from 5.1.19041.1682 to 5.1.19041.2364 (b) (a possible issue first considered by @Bob99 and confirmed by @alejr).

3. I ran the PowerShell query and saw that the last record has an index of 792.

4. I manually started the w32time service and forced it, successfully, to update (c).

5. I re-ran the PowerShell query and saw that the last record still has an index of 792… no further Possible detection of CVE entries have been made (d).

However, I waited an hour then forced another time sync.

Two more Possible detection of CVE events have been recorded:

Reply | Quote

Just another Forum Poster wrote:

However, since the last part of the version info, .2364 matches the new Windows version info displayed after installing the Dec update, it appears it does get updated at least somewhat regularly so mine “may” be more up-to-date.

Yes… well-spotted. 🙂

Reply | Quote

Further testing shows that even with a fully updated install of Windows 10 Pro 22H2, all I have to do to create a new Possible detection of CVE event is to force a time sync then run the PowerShell query again.

As a test I’m going to send multiple requests to force a time sync, spaced a few seconds apart (‘cos… fat-fingered) then screenshot the results when I run the query again (which I’ll have to adjust to take more than 10 events into account).

Currently there are 10 events, with the latest index number of 1928… so I’m going to increase my query to return the newest 25.

Update: Test completed. Every time I sent a (forced) time sync request the Possible detection of CVE events count in the System log increased.

IMO it’s reproducible at will so doesn’t count as a glitch… it’s a bug.

IMO it’s neither time sync nor PowerShell… just the way that PowerShell interprets time changes as potentially threatening (and first mentioned by @Bob99).

However, going back to an earlier post by @alejr (why can’t I ‘mention’ you properly?), I now need to follow up different ‘time sources’ to test your posts.

I’ll change to a different time source, force time sync updates then run the query again now that the OS is up-to-date..

Reply | Quote

Rick Corbett wrote:

I’ll change to a different time source, force time sync updates then run the query again now that the OS is up-to-date..

“At first blush”, I would expect your results to match what you’ve already gotten and what I got since your machine’s OS and version of PS match mine and Al’s.

Still kind of weird how Al got no results but you and I have gotten results out the you-know-what.

I just d/l’d PS 7.3.1 in its .msi form for further testing since it can install alongside PS 5.1. I expect to install and then test in a short while to see if I get the same results or if I perhaps get NO results. I’m referring, of course, to your second query that looks only for event 1 from the kernel itself.

Reply | Quote

Bob99 wrote:

“At first blush”, I would expect your results to match what you’ve already gotten and what I got since your machine’s OS and version of PS match mine and Al’s. Still kind of weird how Al got no results but you and I have gotten results out the you-know-what.

You may well be right… but this issue has surprised me twice by proving my previous assumptions (guesses) wrong. Quite apart from what I think is a PowerShell bug, there HAS to be a reason (or even more than one) why three of us are seeing different results.

It would be great if other’s also chipped in… ‘cos a sample of 3 is really no sample at all.

Maybe I should create a new topic asking for help from others with testing… with step by step instructions? I dunno…

Bob99 wrote:

I just d/l’d PS 7.3.1 in its .msi form for further testing since it can install alongside PS 5.1.

I installed it a while ago… never used it and doubt I ever will. I struggle with built-in… 🙂

Reply | Quote

Wow, version 7.1.3 that’s mentioned in your screenshot was released back on March 11th of 2021!

Versions of PS starting with 7.2.0 feature an update path that uses MS Update within the OS, so any patches/updates for the current flight show up along with the other normal Windows updates in WU. Only reason I know that is from reading the MS documentation about the latest flavors. Right now, they’re maintaining version 7.2 and 7.3, with 7.4 being on the release candidate track with preview 1 that was released just a couple of weeks ago on 20DEC2022. Version 7.2 is up to version 7.2.8 released on 13DEC, same day as 7.3.1.

Version 7.3 will install over 7.0, from what I’ve read in the MS documentation for 7.3. They claim…

PowerShell 7.3 is an in-place upgrade that replaces PowerShell 7.0 and lower.

BUT, it will install alongside 5.1, because it installs to a completely different location, the default directory where you currently have 7.0 installed.

Reply | Quote

Just FYI and as another data point to this discussion.

I also ran multiple force time sync requests and then ran an event log query to see if I got any Possible detection of CVE events with the following result.

Which, exactly as I posted before, shows no results found.

I then ran a standard event log query and got this.

As you can see, unlike Rick, it didn’t log any time sync requests at all even though I am using Windows built in w32 time function (albeit with a “different” time server that the standard time.windows.com that Rick’s using.)

This would seem to indicate that something about my setup is completely different that his but, other that the time server I use, exactly what.

So I ran the w32 /query /configuration command to display exactly how my time function is setup and here’s the result.
(note: I’ve pasted it as text to make a comparison easier.)

PS C:\Windows\System32> w32tm /query /configuration
[Configuration]

EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 54000 (Local)
MaxPosPhaseCorrection: 54000 (Local)
MaxAllowedPhaseOffset: 1 (Local)

FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 360000 (Local)


[TimeProviders]

NtpClient (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 32768 (Local)
Type: NTP (Local)
NtpServer: time-b.nist.gov,0x9 (Local)

NtpServer (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)

VMICTimeProvider (Local)
DllName: C:\WINDOWS\System32\vmictimeprovider.dll (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)

Rick, I’d suggest running this command on your own PC to see if, other that the time server, what else might be different that would explain why our results don’t match?

Rick Corbett wrote:

@alejr (why can’t I ‘mention’ you properly?)

That’s because, unlike most Askwoody users, my “display name” (alejr) and my “profile name” (BigAl67) aren’t the same and, when you use the special @ symbol to ‘mention’ someone, it must point to a valid “profile name” for it to show up in blue (which happens because it creates a “link” to their profile.)

1 user thanked author for this post.

Bob99

Reply | Quote

Hi @BigAl67

I decided to follow your directions and see just what I got with the w32tm /query /configuration command and I got nearly the same results as you, after I started the service in the first place. The only difference I had is in the name of the time server used. Whereas yours said

Just another Forum Poster wrote:

Type: NTP (Local) NtpServer: time-b.nist.gov,0x9 (Local)

Mine said

Type: NoSync (Local)

and there was NO entry for the name of the time server. This is (I believe) because I don’t use Windows’ built-in time service, but another utility (Dimension 4 or D4) that has its own built-in server that performs time queries on its own, so no need for W32Time service.

ALL other entries besides the aforementioned are identical to yours.

BTW, ALL of my PowerShell results thus far have been obtained using version 5.1.19041.2364 that comes with Windows 10 by default. I have yet to try any of these commands on a discrete installation of PowerShell 7.3.1, which I downloaded a couple of days ago.

Now, let’s see if Rick has any differences!

Reply | Quote

Well, I got PS 7.3.1 installed, but for the Get Eventlog command, the below is all I got:

PowerShell 7.3.1
PS C:\Program Files\PowerShell\7> Get-EventLog -LogName System -InstanceId 1 -Source Microsoft-Windows-Kernel-General -Newest 20 | Format-Table
Get-EventLog: The term ‘Get-EventLog’ is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
PS C:\Program Files\PowerShell\7>

Sounds as if 7.3.1 needs some help interpreting the Get command. Could there be a way to add/install another module so that it knows what to do in this case? Or, could it be that the individual variable for the Get command isn’t recognized at all by 7.3.1, whereas it was/is recognized by 5.1?

Reply | Quote

Just another Forum Poster wrote:

Rick, I’d suggest running this command on your own PC to see if, other that the time server, what else might be different that would explain why our results don’t match?

I ran the command on the clean install of 22H2. There was only one difference.

Yours shows:

VMICTimeProvider (Local)
DllName: C:\WINDOWS\System32\vmictimeprovider.dll (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)

Mine doesn’t have that last section at all. I assume it’s because you’re using a virtual machine, otherwise the configuration is identical except for the time source.

Again on the 22H2 clean install I changed time server (using Control Panel) from time.windows.com (a) to time.nist.gov (b):

It made no difference. You can see from the Last Successful Sync Time entry of each time source that it corresponds exactly with the time of the last two Possible detection of CVE events.

The clean install og 22H2 is fully up-to-date and using PowerShell 5.1.19041.2354.

Reply | Quote

Rick Corbett wrote:

Mine doesn’t have that last section at all. I assume it’s because you’re using a virtual machine, otherwise the configuration is identical except for the time source.

Actually, I don’t.

You’ll notice the Enabled parameter is o (disabled) instead of 1 (enabled).

Reply | Quote

Bob99 wrote:

Sounds as if 7.3.1 needs some help interpreting the Get command.

From Get-WinEvent vs. Get-EventLog:

The Get-EventLog cmdlet uses a Win32 API that has been deprecated, so Microsoft recommends using Get-WinEvent. However, Reddit wisdom indicates that Get-WinEvent can sometimes be slower than Get-EventLog.

Reply | Quote

Get-WinEvent also works under powershell 5.1 so I tired replacing Get-EventLog with Get-WinEvent in the command we’ve been using and got this error!

Get-WinEvent : A parameter cannot be found that matches parameter name ‘InstanceId‘.

So I removed the -InstanceID parameter and got this error.

Get-WinEvent : A parameter cannot be found that matches parameter name ‘Source‘.

So I removed the -Source parameter and got this error.

Get-WinEvent : A parameter cannot be found that matches parameter name ‘Newest‘.

So I compared Microsoft’s Get-EventLog support page and their Get-WinEvent support page and discovered Get-WinEvent uses -MaxEvents instead of -Newest, but couldn’t find the equivalent Get-WinEvent parameters for -InstanceId and -Source.

So it’s not as simple as just replacing Get-EventLog with Get-WinEvent because there are some major differences between the parameters used with each one.

1 user thanked author for this post.

Bob99

Reply | Quote

@bigal67 –

Thanks for the effort to try and ferret out just what else might work for PS 7. I’ll start another topic to see if @RetiredGeek or anyone else has any suggestions. I firmly believe you provided a starting point for chasing down the issue of the command not working in 7.3.1 for further investigation.

I’ll do some leg work if I can get pointed to the right area for looking up the command references that exist somewhere on MS’s site for PS 7.

Reply | Quote

Just another Forum Poster wrote:

You’ll notice the Enabled parameter is o (disabled) instead of 1 (enabled).

I did notice… but, more importantly, your OS noticed and reported on it.

Reply | Quote

I just remote-connected into a friend’s Dell Latitude E7440 laptop to do some maintenance and, as an aside, ran the PowerShell query:

She rarely uses it so the timestamps don’t surprise me… but the regularity of the Possible detection of CVE events did.

Could it be just be a laptop thing?

 

Reply | Quote

Rick Corbett wrote:

Could it be just be a laptop thing?

Don’t have a notebook.

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Ok, I did some additional testing on my own laptop and the 6 PC’s my Uncle has that I provide support for and here’s what I found.

My Desktop (Asus Maximus XI Gene motherboard) does not show any possible CVE errors.
My Laptop (Dell D-830) does show the possible CVE errors.

My Uncle’s Desktop (HP Compaq DX7300 MT) does not show any possible CVE errors.
My Uncle’s Laptop (HP Pavilion zt3200) does show the possible CVE errors.

My Aunt’s Laptop (HP 2000-299WM) does show the possible CVE errors.

My Nephew’s Gaming Desktop (Gigabyte Z490 Aorus Master motherboard) does not show any possible CVE errors.
My Nephew’s School Laptop (HP Envy 15m-DR0012DX) does not show any possible CVE errors.
My Nephew’s old Laptop (Dell D-830) does show the possible CVE errors.

So, other that my Nephew’s HP Envy laptop (see below), it does appear that maybe it’s a laptop only thing.

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The fact my Nephew’s School Laptop doesn’t show the error possibly adds another variable into the equation.

That PC is the only one in the above list where the logged in user is “not” a member of the Admin group so maybe that’s also a factor in whether a PC does or doesn’t show the CVE errors.

Reply | Quote

The system I was using in my post above #2513630 is a desktop with an ASRock Z170 Extreme 7+ motherboard installed in 2015.

I am running Windows 10 22H2 Build 19045.2364

My PowerShell version is 5.1.19041.2364

I see all the CVE entries that Rick has shown.

 

 

1 user thanked author for this post.

Rick Corbett

Reply | Quote

Just another Forum Poster wrote:

That PC is the only one in the above list where the logged in user is “not” a member of the Admin group so maybe that’s also a factor in whether a PC does or doesn’t show the CVE errors.

So, from further results from others (thank you all) it *doesn’t* appear to only be a ‘laptop’ thing… but your post querying whether this is only a ‘member of the Administrators‘ group thing is a very cogent question.

I wonder… and thank you.

Back to testing…

Reply | Quote

Rick,

Per your request…

Anything else I can help with?

RG

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

RetiredGeek wrote:

Anything else I can help with?

RG, Yes, my friend… you can help work out what is causing this.

IMO there *has* to be a reason – reproducible – why some people see this issue yet others can’t reproduce it at all.

It *can’t* be random (can it?). There’s one or more causal factors that we’ve not yet thought of…

And PowerShell – which is not my strong point – seems to be at the root of it.

I’m off to create a ‘standard user’ profile on test clean install 22H2 laptop to run PS query again… hampered by not running my usual ‘Windows 10 Decrapifier’ script so all kinds of nonsense is popping up.

Actually I’m going to start over on test laptop… it will probably be quicker than the nonsense that even Edge throws up. Holy heck… how on earth do people deal with such in-your-face silliness with stock installs of Windows 10? At least it will prove whether the ‘Windows 10 Decrapifier’ script is a causal factor (which I already guess it isn’t).

(I never knew before now that in 22H2 you cannot quit out of Edge before completing its initiation wizard. ALT+F4 has no effect whatsoever. Right-clicking on its process in the taskbar and choosing ‘Close’ has no effect whatsover. It’s like the Borg has taken control of your device completely. That’s my next project… stopping new Edge from ever, ever firing… and all the other new gaudy nonsense on the default taskbar).

Rick

For several reasons I’ve stopped using virtual machines, mostly because my hugely over-specified (for its day) 32GB ram Dell 490 Xeon home server has apparently met its silicon maker in the sky. I’m not sure I can revive it… and it’s now ancient… and I’ve been retired for years. I just don’t need that awesome ‘oomph’ any more, nor can I justify the cost of replacing it with more modern ‘oomph’.

The huge advantage of my trusty old Dell Latitude E7450 test laptops with standard 128GB M.2 SSDs is that it takes about the same time to clean install from an MCT USB stick as it does to load the Macrium Reflect Free environment from a USB stick then restore a disk image… less than 5 minutes.

Reply | Quote

1. Clean-installed test laptop (including wiping all partitions) using latest MCT-configured USB stick to install 22H2.
2. Interrupted OOBE and ran modified Windows 10 Decrapifier script whilst in Admin mode. (I just can’t stand the absolute circus that now results in a default install of Windows 10.)
3. Continued OOBE by rebooting in order to complete Sysprep.
4. Continued with ‘limited setup’ by pretending no internet connection in order to create local account.
5. Entered ‘user’ with no password to create default account in Administrators group.
6. Accepted *no* default settings.
7. Continued to new desktop (using ‘User’ account in Administrators group).
8. Settings > Accounts > Family & other users > Add someone else to this PC > newuser.
9. Carried out Sign out > Sign in as newuser.
10. Accepted *none* of the new user nonsense… finally got to new stable desktop.
11. Ignored the Microsoft Edge popup (my next project).
12. Opened Windows Powershell (Admin) console.
13. Ran PS script:

Result:

Possible detection of CVE is still there…

What the heck is causing this?

Is it ‘cos I’m using local accounts?

God help me that I have to use years-old but unused MSA account to test this… but it’s looking that way. 🙁

[snark]Can Microsoft ever make the ‘new user’ experience any more off-putting, ugly or unwelcoming? Yes, probably. No doubt the entire ‘pre-acceptance testing team’ of new builds has been repurposed for this very reason.[/snark]

 

Reply | Quote

RetiredGeek wrote:

Anything else I can help with?

RG.. did you run PS script as elevated or standard user? Local or MSA login? It doesn’t show in your screenshot.

Reply | Quote

JC Zorkoff wrote:

I see all the CVE entries that Rick has shown.

Thank you for testing. I appreciate it.

Reply | Quote

Just another Forum Poster wrote:

That PC is the only one in the above list where the logged in user is “not” a member of the Admin group so maybe that’s also a factor in whether a PC does or doesn’t show the CVE errors.

I think I’ve now tested that… it doesn’t seem to be a factor, but I still have no idea whatsoever why some do and some don’t see this issue.

Don’t you just love ‘puters? 🙂 ROFL

Reply | Quote

Just another Forum Poster wrote:

I think we need a much larger sample size as to who’s system is and isn’t seeing this before we can reach any conclusion about what’s causing it and whether it’s a bug or not.

Still agreeing with you…

Still wondering what else I can test…

Still wishing for MS input… if only to acknowledge ‘bug bounty’ payable to AskWoody forum.

Reply | Quote

satrow wrote:

Don’t have a notebook.

Thank you, satrow. It knocks out another guess of mine.

The conundrum continues… unfortunately.

Reply | Quote

I’m running out of ideas about what to test next.

HUGE thanks to all who have participated in testing so far.

Reply | Quote

@sb – If it waddles like a bug, ‘awks’ like a bug, behaves like a bug… then it’s probably a bug.

You have friends in MS that we don’t. Care to pass this topic on?

I’m done with testing. IMO it’s definitely a bug.

Let the Microsofties work it out (or not)… but any bug bounty comes to AskWoody and you, OK? (‘cos group effort)

[On to next project… killing Borg Edge, and all that it spawns…

Why do you do this, MS? 🙁 ]

 

Reply | Quote

Because it’s a bug that is cosmetic and doesn’t cause damage to data/nor is it a security issue.

No software is perfect.  Microsoft always leaves these cosmetic bugs and unless some really big customer has pain as a result does it get fixed.

This is reality.  I’m not making excuses; I’m just saying that every software has a budget to go after bugs. You may think it’s a big issue, but unless someone who pays a lot more in licensing pushes for fixes – or it’s a security issue – bugs like these are not prioritized.

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

Rick Corbett

Reply | Quote

This is the perfect time to mention that my circumstances have suddenly changed – almost overnight – and I won’t be pursuing this issue any further.

I’m in two minds whether to mark it as resolved. It’s not resolved… but I’m not of a mind to pursue it any further.

3 users thanked author for this post.

Bob99, Just another Forum Poster, satrow

Reply | Quote

@Rick-Corbett –

Due to your sudden extenuating circumstances, I can monitor this thread for any further developments, including a forthcoming update from @sb (hopefully it comes sooner than later, of course).

Meanwhile, I’ll get onto my other computer and log on as a regular “User”, and see what kind of results I get from your little query into the Event Log. I’ll post the results here. However, I just found the following when looking through the PS help files of PS 7,

If you’re not running PowerShell as an Administrator, you might see error messages that you cannot retrieve information about a log.

so we’ll see how I do with PS 5.1.  🤞

Aside from that, the only thing I can think of that hasn’t quite panned out yet is to complete the query using PS 7 or above. I’ll create another topic for that to see if I can get some assistance from @RetiredGeek or another person who may be well versed in PowerShell.

1 user thanked author for this post.

Rick Corbett

Reply | Quote

I’m getting crickets. I’ll keep you posted.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Still a bug though… so eligible for ‘bug bounty’ program? Please pursue… and benefit the forum.

Reply | Quote

Not a security bug.  They only pay bounties for security issue.  They will tell me to post it to the feedback app.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Bob99 wrote:

Due to your sudden extenuating circumstances

ROFL… It turns out that the UK’s ‘Urgent passport renewal’ system is NOT actually all that urgent. Despite the claims of ‘1 hour’ or ‘same day’ service, the earliest ‘urgent’ face-to-face interview and passport collection is next Thursday… but it’s only 31 miles away (in Welsh Wales) so just a walk in the park, despite my impatience.

It’s no biggie… anyone with a 4yr-old will know that their need for attention is nearly always full on, full throttle, 24-hrs or more… so ‘grampy rick’ is off to relieve pressure.

I might leave device on at home and TeamViewer into it… but I doubt it. Instead, I suspect I’ll just go wild… and have beloved daughter hate me for being a bad ‘grampy’ to awesome 4yr-old. ROFL

Sayonara in a week’s time… Spain, here I come! What! I have to wear shorts? I’m nearly 70! Is there no end to this madness?  🙂

Reply | Quote

Rick Corbett wrote:

Sayonara in a week’s time… Spain, here I come! What! I have to wear shorts? I’m nearly 70! Is there no end to this madness? 🙂

Enjoy it while you can!

Reply | Quote

Bob99 wrote:

Due to your sudden extenuating circumstances, I can monitor this thread for any further developments

@Bob99 – I’m very grateful to all who have contributed so far… but, at the end of the day, I think we have all proved conclusively that it’s a very minor bug throwing up a ‘false positive’.

It’s been fascinating to explore all the ‘have you thought of’ posts… it’s what makes this forum so great.

As far as I am concerned it’s a minor bug… so I’m going to mark this topic as ‘resolved’.

Reply | Quote

Wow, so many ‘have you considered…’ posts.

Thank you all. It’s quite clearly a minor bug in my opinion, now tested – I think – to exhaustion.

Reply | Quote

I did a little testing with differing versions of PS:

Powershell ISE - As Admin:
--------------------------
PS> $Msgs = Get-EventLog -LogName System -Newest 20 | 
        Where-Object {$_.message -like "*CVE*"}

PS> $Msgs | fl


Index              : 122986
EntryType          : Information
InstanceId         : 1
Message            : Possible detection of CVE: 2023-01-07T15:43:11.4167167Z
                     Additional Information: 2023-01-07T15:43:11.4164091Z
                     
                     This Event is generated when an attempt to exploit a 
                     known vulnerability (2023-01-07T15:43:11.4167167Z) is 
                     detected.
                     This Event is raised by a User mode process.
                     
Category           : (5)
CategoryNumber     : 5
ReplacementStrings : {2023-01-07T15:43:11.4167167Z, 
                     2023-01-07T15:43:11.4164091Z, 1, 
                     \Device\HarddiskVolume6\Windows\System32\svchost.exe...}
Source             : Microsoft-Windows-Kernel-General
TimeGenerated      : 1/7/2023 10:43:11 AM
TimeWritten        : 1/7/2023 10:43:11 AM
UserName           : NT AUTHORITY\LOCAL SERVICE


PowerShell CMD - As Admin:
--------------------------
$PSModuleAutoLoadPreference set to: None
PS>$Msgs = Get-EventLog -LogName System -Newest 20 |
>>>         Where-Object {$_.message -like "*CVE*"}
PS>$Msgs | fl


Index              : 122986
EntryType          : Information
InstanceId         : 1
Message            : Possible detection of CVE: 2023-01-07T15:43:11.4167167Z
                     Additional Information: 2023-01-07T15:43:11.4164091Z

                     This Event is generated when an attempt to exploit a known vulnerability (2023-01-07T15:43:11.4167167Z) is detected.
                     This Event is raised by a User mode process.

Category           : (5)
CategoryNumber     : 5
ReplacementStrings : {2023-01-07T15:43:11.4167167Z, 2023-01-07T15:43:11.4164091Z, 1, \Device\HarddiskVolume6\Windows\System32\svchost.exe...}
Source             : Microsoft-Windows-Kernel-General
TimeGenerated      : 1/7/2023 10:43:11 AM
TimeWritten        : 1/7/2023 10:43:11 AM
UserName           : NT AUTHORITY\LOCAL SERVICE



PS>

PowerShell CMD - As User:
-------------------------
$PSModuleAutoLoadPreference set to: None
PS>$Msgs = Get-EventLog -LogName System -Newest 20 |
>>>         Where-Object {$_.message -like "*CVE*"}
PS>$msgs | fl


Index              : 122986
EntryType          : Information
InstanceId         : 1
Message            : Possible detection of CVE: 2023-01-07T15:43:11.4167167Z
                     Additional Information: 2023-01-07T15:43:11.4164091Z

                     This Event is generated when an attempt to exploit a known vulnerability (2023-01-07T15:43:11.4167167Z) is detected.
                     This Event is raised by a User mode process.

Category           : (5)
CategoryNumber     : 5
ReplacementStrings : {2023-01-07T15:43:11.4167167Z, 2023-01-07T15:43:11.4164091Z, 1, \Device\HarddiskVolume6\Windows\System32\svchost.exe...}
Source             : Microsoft-Windows-Kernel-General
TimeGenerated      : 1/7/2023 10:43:11 AM
TimeWritten        : 1/7/2023 10:43:11 AM
UserName           : NT AUTHORITY\LOCAL SERVICE


PowerShell 7.2.6 - As Admin:
----------------------------
PSv7.2.6>$Msgs = Get-EventLog -LogName System -Newest 20 |
>>         Where-Object {$_.message -like "*CVE*"}
Get-EventLog: The term 'Get-EventLog' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Can’t see any difference with which version of PS is used with the exception of Core which doesn’t have the command.

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

tl;dr: don’t use Get-EventLog

From “help Get-EventLog”:

               > [!NOTE] > Get-EventLog uses a Win32 API that is deprecated. The results may not be accurate. Use the

               > Get-WinEvent cmdlet instead.

Using Get-WinEvent doesn’t show the bogus results:

               Get-WinEvent -FilterHashtable @{ Logname=’System’; StartTime=[DateTime]’2023/1/2′; ProviderName=’Microsoft-Windows-Time-Service’ }

I ran into a similar issue a couple of years ago. I don’t remember the specifics. But bonus: Get-WinEvent is also much faster.

I tried to post the above response to the AskWoody thread, but WordFence wouldn’t let me. Since I’m not using a VPN and I have a fixed IP address, I guess I’m outta luck. 😊

               N.B.: The fact that the API is deprecated ensures that even if someone has reported it, the report will be ignored.

Thanks.

Regards,

Michael B. Smith

Managing Consultant

It’s a deprecated cmdlet – they won’t fix it.

Susan Bradley Patch Lady/Prudent patcher

5 users thanked author for this post.

Rick Corbett, abbodi86, Just another Forum Poster, satrow, Bob99

Reply | Quote

AhA! I was starting to think that they’d done just that…fixing the bug by deprecation, after rereading the quote that Alejr had posted a while back and experiencing the lack of being able to execute the same thing with PowerShell 7.3.1 and seeing that @RetiredGeek had the same thing happen with PS 7.2.6.

Thanks a LOT for the input.

Now, time for me to uninstall PS 7.3.1, since I only installed it for the purpose of testing to see if it would provide the same results as PS 5.1.

Reply | Quote

The equivalent Get-WinEvent command should be 🙂

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id='1' }

for latest 10

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id='1' } | sort TimeGenerated | select -last 10

Reply | Quote

After changing the “smart” quotes into “standard” quotes…

• remember, our forum S/W always converts them vice versa.

…and removing the StartTime parmeter.

• so it would display all results.

I ran the above Get-WinEvent command using the default Powershell 5.1 and got this result.

So my setup does record time sync errors if they actually occur.

BTW, I still have to wonder exactly why “some” systems (like my desktop, my Uncle’s desktop, and my Nephew’s desktop & laptop) don’t show the Possible detection of CVE error using the older Win32 API Get-EventLog command while others do

Reply | Quote

Alejr,

That’s exactly the same reason that the old Get-WMIObject shouldn’t be used and instead use Get-CIMInstance…

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

It likely depends on how old the OS on those systems are and whether AMSI is enabled.

Reply | Quote

All 8 of the PC’s I tested (see my post #2515006 above) are either Win10 Pro (my Desktop & Laptop and my Uncle’s Desktop) or Win10 Home (my Uncle’s Laptop, my Nephew’s Desktop & 2 Laptops, and my Aunt’s Laptop) upgraded to 22H2, patched to build 19045.2364 (Dec CU update) and running the “same” antivirus S/W.

So, even though they’re all at the same OS level, 4 of them didn’t show that error while 4 of them did.

Other than the fact all the ones that did show the error were laptops (which was discounted as a possibility since my Nephew’s School laptop didn’t show it), what’s causing the different result.

Reply | Quote

What peers do you have set?
Run this to check:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters

cheers, Paul

Reply | Quote

Paul T wrote:

What peers do you have set?

As I pointed out back in my post #2513208 earlier in this thread, I use time-b-nist.gov as the time sever for my PC’s.

And the 6 PC’s I support for my Uncle all still use the Windows default time server which is time.windows.com.

So differences in time servers was also eliminated as a possible cause of the error message.

Reply | Quote

Just another Forum Poster wrote:

I use time-b-nist.gov

You think you do, but I’d check to be sure, thus my question.

cheers, Paul

Reply | Quote

Paul T wrote:

You think you do, but I’d check to be sure, thus my question.

If you actually read all my posts, you’d see that I did verify that’s my actual timer using both regedit and a powershell command!

Reply | Quote

You’ve mentioned 3 services, windows.time, time.nist and time-b.nist, so I was confused.

cheers, Paul

Reply | Quote

abbodi86 wrote:

The equivalent Get-WinEvent command should be 🙂

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id='1' }

for latest 10

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id='1' } | sort TimeGenerated | select -last 10

I couldn’t get the results of the second query to correlate to the first 10 results in the first query. I had to use the following query instead:

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id='1' } | select -first 10

… i.e. remove sort TimeGenerated and use -first 10, not -last 10.

It’s been interesting, mainly because I wasn’t even aware that Get-EventLog was deprecated.

I could have saved myself a lot of time if just one of the articles I read had mentioned it… so I’ve learned something more about PowerShell. 🙂

Reply | Quote

Indeed
for unpatched OS, the message you get is less scarier 🙂
“The description for Event ID ‘1’ in Source ‘Microsoft-Windows-Kernel-General’ cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message..”

Reply | Quote