A Microsoft patch is part of the Security Development Lifecycle (SDL) process. Whenever a security patch is required, Microsoft reviews the patch to ask "why did this happen, and what can we do to prevent it from happening again?" That process often involves a review of the code surrounding the area where the problem occurred. If it occurred because of a false assumption or a logic error, there's a chance that other areas of the code have similar problems that haven't been found yet. If new problems are found, it makes sense to fix them at the same time.
The white-hat researchers that report security problems know when their issues are fixed, since the security bulletin usually includes a "hat-tip" thanking them. The issues found by Microsoft during their own internal review don't necessarily need to be reported, especially if there seem to be no public exploits or knowledge they exist. That's how we get to situations like the Microsoft stealth fixes found by Core Security.
However, there's one complication with this just-fix-don't-tell policy. Once the patch is released, the bad guys can see what's been changed by comparing the old code to the patched code. They often do this to determine how they can exploit a particular problem. If some undisclosed-but-fixed problem is in there, the bad guys may be able to exploit it as well. Yet if Microsoft were to openly disclose the problems found during internal reviews, it's even more likely those problems would be exploited. Therein lies the conundrum.
Although some reports have made it appear that Microsoft is hiding important information from its customers, I don't see it that way. There's a very simple practice that can make the "disclose or don't" issue a non-problem for your organization: Apply patches as soon as possible. That way you'll be protected against both the disclosed and undisclosed problems.