It's a good paper, but note that this is an attack on the (old) per-process RC4-based WRNG, not on CTR_DRBG. The attack essentially observes that if you get RCE on a Windows process and capture the WRNG state, you can get all previous and future states bounded by when the per-process WRNG reseeds (the seeding process reads random bytes from KSecDD, a sort of Windows equivalent of /dev/random).
The Windows design is interesting in that it runs a userland CSPRNG for each process, rather than a single kernel RNG like Linux/Unix provides, but still binds those RNGs to the kernel RNG. This seems like a good idea at first, but turns out not to be: the attack wouldn't be possible if KSecDD was the entire CSPRNG interface for Windows.
Unix also provides many userspace PRNG, for performance or other reasons. But programs have the option of using the kernel directly whenever security matters. Is it even possible on Windows to query directly to kernel randomness with documented APIs?
The Windows design is interesting in that it runs a userland CSPRNG for each process, rather than a single kernel RNG like Linux/Unix provides, but still binds those RNGs to the kernel RNG. This seems like a good idea at first, but turns out not to be: the attack wouldn't be possible if KSecDD was the entire CSPRNG interface for Windows.