by n3evl » Mon Jul 06, 2015 8:53 pm
OK, the character of the problem has change quite a bit since I last posted. It turns out some of my previous observations were in error. So here is what I think is happening:
Our 'normal' windows user logs in to windows and runs an application that requests our injection service to begin injecting our dll.
Our injection service is working normally - we inject our dll into the list of processes including system processes when we invoke InjectLibraryA for both 32 and 64-bit processes
We specify an exclusion list for processes into which we do not want to inject our dll.
Later, another process (Excel) is run as administrator by our 'normal' user.
The run-as-admin attempt causes a new process (that runs ..\windows\system32\consent.exe) to be created
Somewhere behind the scenes, Madshi code attempts to inject into the new consent.exe process and from this point, Windows becomes unstable.
Consent.exe IS listed in the process exclusion list supplied to the initial InjectLibraryA calls.
I think the Windows instability is actually due to some things we do in the injected dll such as some of our hooked functions get invoked and in these we are accessing shared memory. However, this only appears to be a problem when done in the context of the 'Consent' process. So, I guess I'd prefer not to inject into that process at all.
Assuming the above makes any kind of sense, should the behind-the-scenes injection into this process occur even though we specified the name in the exclusion list earlier? Since we do not appear to be in control of injections performed after InjectLibraryA has been called, I can't see any way to prevent the injection into this specific process .