(Mar 18, 2024 04:31 PM)NulldB Wrote:  Am I reading this wrong or can the
"Known Concerns / Dev Notes" have a positive malicious use

Great read though! Again HQ as always

(Mar 18, 2024 06:08 PM)nodes Wrote:  The known concerns, to me, are flaws in the exact definition of what this tool does for auto-unloading. It's also basically a list of things I'd assume people would call out because this tool can't prevent a module from loading 100% as-is.

I'm sure any tool can be used for malicious uses, as people will always find a way to use products for BH activities - even Microsoft & Apple can't stop people using their products for that.

If I had to theorize how the known concerns could possibly be used, a red team could use that knowledge:
- using a dummy dynamic module can prevent another module from being loaded, if you have priority in load order
- using an internal, static module can prevent another module of same name being loaded

---

edit:
important to note that it is highly unlikely you'll be able to utilize this just on its own simply by naming something the same & throwing it in CWD. this preload method specifically require best practices for library loading to be ignored - but over years many softwares have had this vuln .

---

Depending on the blue team / anti-* software, it may be possible to even use default load order just by placing a dummy dll somewhere & not even loading it into your own program. For example, if a software checks a path that your program has access to, the dummy dll can be placed into it causing that other program to use it.

Any program that doesn't clear out their CWD as a potential dll path that also uses loadlibrary or similar is vulnerable to a pre-loading attack due to load order priority:

- For example, if you know my software calls "user32.dll" without a path, you can put user32.dll into the run-directory of my program and I'll call your dll instead of the default one I want.
That's outlined here on an official MS page: https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1

Red teams may be interested in pre-loading DLLs by statically linking their own versions (or dummy dll files).

Red teams may also try to do something like unloading a detected unapproved module and then on-the-fly creating a dll of the same name, to try to load it before the real dll can re-load into the program. However, I am not sure if this works because of load orders and such & the 'calling program' would most likely use a direct path to their own dll to load into yours - it wouldn't call loadlib functions from your program (which is how CWD is taken advantage of in preloading).
- However, blue teams could also make the mistake of loading a library via search (like 'test.dll' instead of 'path/to/test.dll' ) and then getting the path after it's dynamically resolved, and then they could push that dll to your program. In this case the red team could put test.dll into the CWD of blueteam's anti* software so that it pulls the dummy test.dll before pushing that into red team's program. However this is total theory and requires blue team to be vulnerable to pre-loading and also relying on that same vuln to find the path to a target driver they're pushing to yours. This is very unlikely to happen in this sequence imo.

(Mar 18, 2024 10:37 PM)SIM-5457022 Wrote:  So, what you're saying that when we write our programs we better double check what files it's grabbing and make sure it's a legit dll that needs to be loaded and not a fake one that a hacker has laying around in the same folder as the program.

(Mar 19, 2024 12:43 AM)ttbr0 Wrote:  code looks good for unloading dlls. great work! something to note is that modules have reference counts for however many times LoadLibrary was called on it. calling FreeLibrary once may not unload the module so you need to check the reference count and unload it until it is zero and the library actually gets unloaded. i believe the reference count is in the peb's LDR_DATA_TABLE_ENTRY which you already know from your previous thread on peb walking.

some suggestions for keeping dlls unloaded:

1. primitive method, but you could hook LoadLibrary or LdrLoadDll or NtMapViewOfSection and check the dll name
2. consider using the PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON mitigation to prevent non ms signed binaries from being loaded into the process (probably sufficient for most use cases since ms binaries are not malicious)
3. quite aggressive but using the PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON mitigation could prevent manual mapping of dlls. there are compatibility issues with dynamic code, so a process with the c# runtime might implode

(Mar 19, 2024 07:29 AM)nodes Wrote:  Thanks, I appreciate that a lot!
The reference counts is something I did read about, but honestly forgot about that issue. I'm going to update this to use the PEB count & make sure all are unloaded no matter what. Thanks for this reminder :)

I am not familiar with the flags/definitions you provided for the policies but am going to look into those to see how that can work.
- I appreciate your comments across my threads man! You seem like an HQ user

---

Update for blue teams
- although anti-ransomware on 1 provider was bypassed w/ unloading method, the signature detect was fast
- I have now broken the anti-ransomware from 2 separate codebases using unloading
- at this time I haven't determined how the signature is detected or if it's possible for a read team to re-bypass without rewriting/recompiling their code

(Mar 18, 2024 11:13 PM)nodes Wrote:  I feel like 90% of git is probably vulnerable to load priority in the program directory

(Mar 19, 2024 06:18 PM)ttbr0 Wrote:  thanks dude, happy to help someone who is into research and improving their skills! i just remembered that dll pinning exists using GetModuleHandleEx with the GET_MODULE_HANDLE_EX_FLAG_PIN flag which makes FreeLibrary refuse to decrement reference counts and unload the library. from what i quickly looked at, it seems to just set the peb reference count to 0xFFFF as an identifier for pinning. unsetting that should easily undo the pinning.

(Mar 19, 2024 11:54 PM)SIM-5457022 Wrote:  but to combat the load priority issue would we as programmers need to double check
which files to load into our program? Should we be checking signatures that are signed?

what would avoid getting a load priority vulnerability?

(Mar 18, 2024 03:28 PM)nodes Wrote:  -

(Apr 19, 2024 12:02 PM)dasdas543534534 Wrote:  Cute but won't work against statically linked DLL's that are abused for side loading. (You can reverse engineer why)

As far as code:

Code

HMODULE hModules[1024];
DWORD cbNeeded;

Always initialize variables.

Code

for (int i = 0; i < moduleCount; i++) {

Ugly, will never be used in production code, use std::span and for each loop.

Code

std::string moduleName = szModName;

Un-necessary copy created, if you know you don't need szModName anymore, use std::move, or std::string_view?



This entire code :

Code

bool UnloadDllByName(std::string dllName) {
    HMODULE hModule = GetModuleHandleA(dllName.c_str()); // Use ANSI version directly
    if (hModule == NULL) {
        std::cerr << "DLL not found: " << dllName << std::endl;
        return false;
    }

    if (FreeLibrary(hModule)) {
        std::cout << "DLL unloaded successfully: " << dllName << std::endl << std::endl;
        return true;
    } else {
        std::cerr << "Failed to unload DLL: " << dllName << std::endl << std::endl;
        return false;
    }
}

Can be converted to :

Code

return GetModuleHandleA(dllName.c_str()) ? FreeLibrary(hModule) : false;

Code

int intervalMilliseconds = 500

Why not const?

(Apr 23, 2024 07:21 AM)nucleo_type09 Wrote:  Looks good, bro. You just need a bit more practice with C++, but your PoC looks nice. Even though, I would suggest using const where possible. Constants are allocated in the program's data segment, and using stack allocations instead of heap is preferable, as they're faster. By the way, how are you? Have you left the company you were working with? :)

(Apr 23, 2024 07:42 AM)nodes Wrote:  Hey thanks for this, and yes agreed. Going back to some basics with C/C++ instead of getting too advanced too quickly so I can have a better foundation.

Not yet lol, just stressing and losing hair still!