The answer is: You should not need to know this. As stated in the accepted answer to a related question:
A GUID doesn’t make guarantees about randomness, it makes guarantees around uniqueness.
An even stronger statement on security and randomness is made in RFC4122, which speficies the UUID format:
Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access), for example. A predictable random number source will
exacerbate the situation.
Anything else is an implementation detail (and might be subject change).
Windows specifics
Often, people claim that the behavior on Windows is documented and that it is therefore guaranteed that GUIDs are cryptographically secure.
The now archived [MS-SECO] Windows Security Overview document mentions in Appendix A:
Although only a small minority of version 4 GUIDs require
cryptographic randomness, the random bits for all version 4 GUIDs built in Windows are obtained
via the Windows CryptGenRandom cryptographic API or the equivalent, the same source that is used
for generation of cryptographic keys.
Moreover, section 2.5.5 of the same document explicitly mentions the use of “secret GUID” values as nonce or authenticator.
BUT: This piece of product behavior documentation is not a specification you can generally base the security of your product on (in particular in the context of .NET).
In fact, the document above describes an implementation detail of a particular product.
Even if the current Windows and .NET Framework 4.x implementations produce truly random version 4 UUID values on Windows, there is no guarantee that System.Guid.NewGuid will do so in the future or on other .NET platforms (e.g. Mono, Silverlight, CF, .NET Core, etc).
Just as an example, the UUID algorithm used in earlier versions of .NET Core depends on the platform and you might get a version 1 UUID (on BSD).