I've done some digging and come up with what I think is useful information for you if you have a custom error handling solution in place instead of or as well as the usual ASP.NET <customErrors> stuff.
From comments on ScottGu's post it seem to be that the main suspect to be the actual padding oracle is WebResource.axd (possibly other axd's).
- If you look in .NET Reflector at the IHttpHandler.ProcessRequest method in System.Web.Handlers.AssemblyResourceLoader there's a call to Page.DecryptString early on.
- This is the thing that will cause a HTTP 500 status to be returned if it fails, e.g. if the padding, etc in Request.QueryString["d"] is invalid
- If the attacker manages to get the padding right, then it continues on, ultimately to call throw new HttpException(404...)
It's this differentiation: is the padding correct (404) or not (500) that is at the root of the exploit: the padding oracle.
If your error handling returns exactly the same response for both - it masks the oracle. To test if you're vulnerable externally, a simple test is to request both: