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?

3 Answers 3


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.

  • Out of interest, what version of Windows did Microsoft straighten out the permissions on the Programme Files folder? Commented Dec 28, 2015 at 8:46
  • 2
    It actually was always a feature of NT-based OS at least since Windows 2000 (possibly NT4) when installed over NTFS but, in Windows XP (and previous), it was mostly ignored: users where usually running as administrator. When UAC was released with Vista, things changed since even "administrators" account could not write to %programFiles% without elevation.
    – Stephane
    Commented Dec 28, 2015 at 8:54

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.

  • I fail to see why shim dlls would have to be installed in %Appdata%: there is no part of the shimming process (as I understand it) that requires non-admin users to have write access to these files.
    – Stephane
    Commented Dec 28, 2015 at 9:00
  • How is this not proper for distribution? Even Microsoft distributes programs this way. This ensures the application they have permission to their own dependencies without having unnecessary permission elevations/requirements. And it also helps prevent "DLL Hell" conflicts and gives the developer full control of their dependency management. Not all DLLs are Windows system files or third party libraries either. So putting those in a system folder would cause unnecessary complications for no added benefit.
    – Bacon Brad
    Commented Jan 29, 2016 at 18:51
  • @Stephane A user profile might not be allowed to access a DLL based on it's location and/or permissions or some UAC access/scope. %Appdata% is stored in the user's directory ensuring (or assuming the likelyhood) they have full access to it's contents.
    – Bacon Brad
    Commented Jan 29, 2016 at 18:56

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .