The foundations for the attack are described here by James Kirby, but put simply, Windows File Protection is made possible thanks to sfc.dll which is loaded by winlogon.exe. This DLL file exports an unnamed and undocumented function known simply by it's Ordinal - #2, which essentially unloads file protection. The attack is simple: the address of Ordinal #2 is determined, then a call to CreateRemoteThread is made with the thread start address being the address of Ordinal #2. The thread begins execution and Windows File Protection unloads immediately. System files can then be modified.

SOLUTION: DiamondCS ProcessGuard (even with just the default, wizard-generated configuration) protects against this by blocking the attacking process from creating a remote thread in winlogon.exe. It accomplishes this by denying WRITE  access (which required to create remote threads) - it's that simple.

Case Example:
We created our own tool called WFPDisable.exe which executes the attack to disable Windows File Protection. We ran it under normal conditions, and as expected the attack was successful. Then we ran it on a system that was secured by DiamondCS ProcessGuard, and as expected the attack was blocked:

Looking at the main ProcessGuard window we can see the blocked attack in detail:

DiamondCS ProcessGuard has blocked the attack, and Windows File Protection is still active.

Related websites:
 MSDN: About Windows File Protection
 MSDN: Windows File Protection on Windows 2000 and Windows XP