So let me get this straight... Some malware that somehow finds itself executing on a DC with sufficient local system access (not necessarily "domain admin") can alter the in-memory code of the authentication process and insert its own tweaks to let specific passwords through as well as the correct ones.
Clever but, well, duh. When a process has full access to all memory in a system it can make all kinds of interesting changes but isn't this what ALSR was meant to help to partially mitigate? ALSR can't fix this problem entirely as the executable needs to be discoverable somehow, it just makes it harder as the attacker has to put more effort into finding the correct memory location to patch. Other than this, good luck fixing as Windows isn't designed to segregate application memory space in this way when a user with local admin access is involved and continually security monitoring or reloading in-memory images is CPU intensive.
As noted previously, when a user with sufficient privelidges is compromised, you have a lot of problems and this is just an example of one. Pretty much why Best Practice dictates that no user should ever have such access on their normal account and instead have a separate admin account which they use on the occasions that they genuinely need to perform system administration. This doesn't make the problem go away, but it does help to reduce the chances.
Biting the hand that feeds IT
