bytecode77 / r77-rootkit

Fileless ring 3 rootkit with installer and persistence that hides processes, files, network connections, etc.
https://bytecode77.com/r77-rootkit
BSD 2-Clause "Simplified" License
1.61k stars 392 forks source link

Significant challenge with BitDefender AV (BD) that affects the operation of admin-level processes #77

Closed Ogyeet10 closed 5 months ago

Ogyeet10 commented 5 months ago

I've encountered a significant challenge with BitDefender (BD) that affects the operation of admin-level processes injected by r77. During tests in my r77 BD VM, I noticed that several critical applications fail to launch due to BD interventions. For example, BD terminates certain processes that the Windows Settings app depends on(therefore it fails to even appear on screen for a split second). The most frequently flagged process is icacls, but this issue extends to any admin process that has been injected by r77, such as regedit and settings.

Issues Encountered:

Given these problems, BD's aggressive detection and termination tactics have rendered the r77 rootkit ineffective. This is because avoiding the injection of admin processes to circumvent BD detection compromises the fundamental capabilities of the rootkit. For example, if regedit (an admin process) isn't injected, a curious user may stumble upon the $77config reg key.

Temporary Measures and Further Investigation:

For the moment, I am considering detecting BD by checking for the existence of its installation directories, and if detected, aborting the installation script. This failure will then be logged to my command and control (C&C) server for further analysis. However, this is far from a perfect solution as it essentially admits defeat against BD's security measures.

Possible Solutions:

Assistance:

I am not smart enough to look into why BitDefender is flagging all admin processes but my best guess is BD puts more effort into checking admin prosseses as those can do the most damage and therefore finds something related to r77 in the processes memory.

I've paused research into the scheduled task file as this issue is now my main concern.

As you said it's probably getting flagged due to a yara rule (which you don't fix).

PS I'll move to the shellcode installer cause my current solution only works for Windows Defender and select others.

If you have any ideas or potential updates(to r77) that could address these challenges, please share them. I am open to exploring all possible avenues to enhance r77’s resilience against BD (and other AVs).

(sorry if I kinda rambled, I wanted to cover a lot)

This is a continuation of https://github.com/bytecode77/r77-rootkit/issues/76

bytecode77 commented 5 months ago

I've once had similar issues with ESET, reported in #10. This particular AV blocked r77, which is when I have introduced AMSI bypass in the first place as a generic method to bypass detection in that particular installation stage. Later I have introduced polymorphism thereby defeating Windows Defender until now (6 months later).

But then again I have discovered that ESET went crazy as it detected r77 and offered to "clean and reboot the system". It did reboot the system only to offer a reboot once more. So yes, I've seen this kind of quirky behavior before, where AV could not clean r77, but still forced a reboot.

I see a yara rule here that contains a lot of strings. I guess you could try to obfuscate them and see whether this helps. I suggest you try various things and see how BD reacts.

Side note: Make sure that you have written down your Bitlocker Recovery Key! If you introduce a bug at the wrong place, your OS will crash and only boot in recovery mode, where the recovery key is requires. This only applies, if your system drive is encrypted.

Ogyeet10 commented 5 months ago

Hey, thanks for the info.

Luckily my PC’s powerful enough that I can run everything I need in a VM, I don’t run BitLocker on my PC anyway, so this wouldn’t be an issue. I'm probably not going to end up obfuscating those strings, if ever. I just don’t have the experience to do so. Sure, I program, but not for native Windows apps and DLLs.

Side note: While waiting for a response from you, I was setting up an AV allowlist in my setup script. As it implies, it only runs the install script if only whitelisted AVs exist on the target system.

I'm using your script, PEUnion, for my script as it’s just more convenient for my script to download one file, rather than needing 3. I will eventually move to a 2-stage allowlist system, where if it doesn't pass the first allowlist it will be checked against the other allowlist. This includes checks like if the target system has tamper protection in WD enabled, or if they have an AV like Malwarebytes enabled that, like WD, only flags the installer file, but can’t be disabled with PS commands.

If an AV is on the second but not the first whitelist, I'll use more stealthy ways, less convenient ways of installing, such as the shellcode installer, as you suggested. I’m not sure what I’ll do about my other AV sensitive programs that I need though (none from you).

Current Status:

At least for me right now, r77 is invisible to WD (which the majority of users run) and if it ever becomes detectable, I’ll just add whatever file is flagged to the exceptions using PS. The technical level of users I'm targeting (my friends, lol) is quite low, so I doubt they are going to check, or remove their exceptions at any point. The script is designed so I only need split-second (about 15 seconds) access to the target's system in order to trigger it. That's just me bragging though.

Closing Thoughts:

I figure I’ve taken up enough of your time with my side note. You probably have more important things to get to. Anyway, thanks for your help. I’ll close this issue. If I have any updates or need more help, I’ll reopen it.

Thanks,
Aidan