Are .dll files normally found in system32 but now in a user’s AppData folder always suspicious?

Since Microsoft has straightened the default permissions on the Program Files folder, many developers have turned to AppData as an alternative location for their code. The logic being that an application installed this way can be updated without requiring elevation or admin level access. (Google Chrome, for instance, does this).

This also means that, sometimes, you will find legitimate libraries that usually live in the system32 folder somewhere under the AppData path. These usually are run-time components (like the MSVCRT, GDI+ or capicom) that are maintained and updated by the application itself (usually because they require a specific version to work but sometimes because they are pushed as a user component instead of a system one and needs to be deployed without elevation).

That does not mean that you should find libraries belonging to the operating system there: there is no legitimate reason for, say, schannel.dll to be found there since the only application that maintain that library is the operating system.

So, dlls under AppData having the same name as a dll in system32 are not automatically suspicious.

While not proper for distribution, another reason someone might use the %appdata% path for system libraries would be for run-time shimming.

Specifically: If I wanted to have run-time inspection into a given API contract validation (a common example being malloc/free, but this is already managed by AppVerifier) or general usage profiling, I could write a shim layer which performs the validation, then passes on to the legitimate system library.

In general, system libraries should be in the appropriate system or SXS path. All those with Windows Logo Certification will adhere to this, but many apps distribute without certification.