Can Windows Load-Time Dynamic Linking be overrided?

Question

I am a graduate student, working on Windows API hooking. I know that it is not easy to replace a Protected DLL in System32 folder with a modified DLL. But I was looking if there is a way, such that I can change/override the Windows Dynamic DLL Linker that I can hook Windows API globally, without using any other System APIs?

My intention is to profile Powershell scripts globally in order to any monitor byzantine behavior. Hooking was the first thought that came into my mind.

I looked for answers in Windows Internal Book (6th edition), but couldn't find any theory based on this. A reference would also be appreciated.

Thanks.

Answer 1

It is possible to use an old feature called Detours. There's a registry key called AppInit_DLLs which contains a list of libraries that get loaded into every process at start. This is used by Sophos Anti-Virus, for example. It is truly global, AFAIK. Every single process checks that on process creation. However, potentially relevant discussion here: Preventing a DLL file from loading into my process via MS Detours

However, if it's specifically Powershell that you want to monitor, and you can count on PSv5 and above, Powershell gives you some very powerful native functionality to both monitor and constrain. You will likely be better off using this.

The absolute ne plus ultra whitepaper is titled Securing PowerShell in the Enterprise and is published by the Australian Cyber Security Centre here. I imagine they will keep it there for a long time, being a government body, but even if that goes dark you should be able to find a copy with your search engine of choice. It is regularly updated; at time of writing it shows "March 2019" and contains this helpful rider:

Organisations or individuals with questions regarding this advice can contact the ACSC by emailing asd.assist at defence.gov.au or calling 1300 CYBER1 (1300 292 371).

To the Australian Signals Directorate, thank you. Since that's an Australian number, don't forget to hold your telephone upside-down.

In the spirit of SO, I'll give you a precis. The document lays out a sequence of achievable steps to get from a low to high security. The stages are:

• Default configuration
• Script Whitelisting
• Code signing for scripts
• PSv5
• Central logging and transcription
• Role-based whitelisting
• WinRM hardening
• Constrained endpoints

The whole document is 20 pages, so it's not a big time investment. But since your question appears to deal with the Central logging and transcription section, here's a relevant excerpt showing the capabilities:

• Engine Lifecycle Logging: PowerShell logs the start-up and termination of PowerShell hosts. PowerShell version 5.0 has the ability to log the command-line arguments passed to the PowerShell host, including PowerShell code passed to powershell.exe via the command line. Engine lifecycle logging is enabled by default and can be found in the Applications and Services Logs\Microsoft\Windows\PowerShell\Operational log.
• Module/Pipeline Logging: PowerShell version 3.0 and later can log pipeline events to Windows Event Logs on a per-module basis or on a global basis. This can be set via Group Policy.
• Script Block Tracing: PowerShell version 5.0 can log detailed information including what code was run and is output to the Windows Operational Event Log.
• Transcripting: PowerShell version 5.0 allows for the transcription of code in all PowerShell hosts and can be controlled by Group Policy. While very powerful, transcripts do not integrate into Windows Event Logs and will need to be managed as on disk files.

Here's an excerpt from the appendix relevant to that section:

I'm not sure exactly where you're going with this, but it seems to me that this paper might be useful to you.