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

Question

I recently had to read over some malware reports and associated logs for a confirmed malware detection and subsequent infection of a Windows asset. The logs clearly show .dll files in a user’s AppData folder. These .dll files are named the same as .dlls normally found in system32, e.g cryptbase.dll.

I know that in this specific instance this was definitely malware and the unpacking of the rogue .dlls was part of the malware's normal process. I asked about this in chat and was told that the only real credible explanation for this behaviour would be malware (as it was in this instance) or very bad programming practice, and even in that case it is a scenario that is rare.

My question is twofold; is there a scenario where .dll files with the same name as standard system32 .dlls be found in an user's AppData folder for any reason other than malware or poor programming?

In addition, is it fair to treat .dll files that are found in AppData and appear to be copies of .dll files in system32, as an indicator of compromise?

Answer 1

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.

Answer 2

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.

Answer 3

I'd call it bad programming if you actually overwrite Windows' default DLLs. Putting them in another location than System32 is a way to:

• Use an exact DLL version without depending on the system. (Example: Direct 9's DLLs aren't included by default on Windows 10, and any game that depends on that crashes)
• Update executables without admin rights (Firefox and Chrome does that)
• Overwrite a system DLL only for your app (Why would you do that in the first place)

If a software is well made, it will put DLLs in AppData or its installation directory instead of in System32.

If a malware is well made, it will put DLLs in System32.