Les fichiers .dll se trouvent-ils normalement dans system32 mais maintenant dans le dossier AppData d'un utilisateur sont-ils toujours suspects?
J'ai récemment dû lire certains rapports sur les logiciels malveillants et les journaux associés pour une détection confirmée des logiciels malveillants et une infection ultérieure d'un actif Windows. Les journaux indiquent clairement .dll fichiers dans le dossier AppData d'un utilisateur. Celles-ci .dll les fichiers portent le même nom que .dlls normalement trouvé dans system32, par exemple cryptbase.dll.
Je sais que dans ce cas précis, il s'agissait définitivement d'un malware et du déballage du voyou .dlls faisait partie du processus normal du malware. J'ai posé des questions à ce sujet dans le chat et on m'a dit que la seule véritable explication crédible de ce comportement serait un logiciel malveillant (comme c'était le cas dans ce cas) ou une très mauvaise pratique de programmation, et même dans ce cas, c'est un scénario rare.
Ma question est double; existe-t-il un scénario où .dll fichiers portant le même nom que la norme system32.dllsont-ils trouvés dans le dossier AppData d'un utilisateur pour une raison autre qu'un malware ou une mauvaise programmation?
En outre, est-il juste de traiter .dll fichiers qui se trouvent dans AppData et semblent être des copies de .dll fichiers dans system32, comme indicateur de compromis?
Étant donné que Microsoft a redressé les autorisations par défaut sur le Program Files, de nombreux développeurs se sont tournés vers AppData comme emplacement alternatif pour leur code. La logique étant qu'une application installée de cette façon peut être mise à jour sans nécessiter d'élévation ou d'accès au niveau administrateur. (Google Chrome, par exemple, fait cela).
Cela signifie également que, parfois, vous trouverez des bibliothèques légitimes qui vivent généralement dans le system32 dossier quelque part sous le chemin AppData. Ce sont généralement des composants d'exécution (comme MSVCRT, GDI + ou capicom) qui sont maintenus et mis à jour par l'application elle-même (généralement parce qu'ils nécessitent une version spécifique pour fonctionner mais parfois parce qu'ils sont poussés en tant que composant utilisateur au lieu d'un composant système) et doit être déployé sans élévation).
Cela ne signifie pas que vous devez y trouver des bibliothèques appartenant au système d'exploitation: il n'y a pas de raison légitime pour, disons, schannel.dll d'y être trouvé car la seule application qui maintient cette bibliothèque est le système d'exploitation.
Ainsi, les DLL sous AppData portant le même nom qu'une DLL dans system32 sont pas automatiquement suspects.
Bien qu'il ne soit pas approprié pour la distribution , une autre raison pour laquelle quelqu'un pourrait utiliser le %appdata% le chemin des bibliothèques système serait pour le calage au moment de l'exécution.
Spécifiquement : Si je voulais avoir une inspection d'exécution dans une validation de contrat API donnée (un exemple courant étant malloc/free, mais cela est déjà géré par AppVerifier) ou le profilage d'utilisation générale, je pourrais écrire une couche shim qui effectue la validation, puis passe à la bibliothèque système légitime.
En général, les bibliothèques système doivent être dans le système approprié ou SXS chemin. Tous ceux avec Windows Logo Certification y adhéreront, mais de nombreuses applications distribuent sans certification.
J'appellerais cela une mauvaise programmation si vous remplacez réellement les DLL par défaut de Windows. Les placer dans un autre emplacement que System32 est un moyen de:
- Utilisez une version exacte DLL sans dépendre du système. (Exemple: les DLL de Direct 9 ne sont pas incluses par défaut sur Windows 10, et tout jeu qui en dépend se bloque)
- Mettre à jour les exécutables sans droits d'administrateur (Firefox et Chrome fait cela)
- Écraser un système DLL uniquement pour votre application (pourquoi le feriez-vous en premier lieu)
Si un logiciel est bien conçu, il placera les DLL dans AppData ou son répertoire d'installation au lieu de System32.
Si un malware est bien conçu, il mettra des DLL dans System32.