Preface: Software application could allow an authenticated, local attacker to perform a DLL hijacking attack. To exploit this vulnerability, the attacker would need to have valid credentials on the Windows system.

Vulnerability details: If workstation install Python, by default it will install on the C Driver :\directory instead of the C Drive:\Program Files. Therefore the authenticated users will have write access in that directory. If user compromised by phishing attack. This give a way to conducting the privilege escalation because the attacker can share the authenticated user permission write a malicious DLL in Python program directory. When the computer reboot in next time the process will restart with the permission of that process. The vulnerability is due to insufficient validation of resources that are loaded by the application at run time. Or, it is a programming technique misused? Whether, it is a unknown matter?

Scenario of attack:

• An attacker could plant a DLL with the same name earlier in the import resolution search path, such as the application directory. Protected directories are more difficult – but not impossible – for an attacker to change.
• If the DLL is missing from the application, %windows%\system32, and %windows% directories, import resolution falls through to the current directory. An attacker could plant a DLL there.

Microsoft’s remedy: If you specify the link option /DEPENDENTLOADFLAG:0x800 (the value of the flag LOAD_LIBRARY_SEARCH_SYSTEM32), then the module search path is limited to the %windows%\system32 directory. It offers some protection from planting attacks on the other directories.