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.59k stars 389 forks source link

How to hide specific files, directories, registries as I want? #9

Closed GV13057911485 closed 3 years ago

GV13057911485 commented 3 years ago

Hello Bytecode77,

Just like to say thank you prior to any suggestion! I love r77 so much, really neat and clever fileless design.

now I would like to open a new issue publicly, so more and more users will join this topic.

Up to now, I did many tests upon this rootkit and happy to see almost all functions are correct as you described in the documentation, amazing!

I would like r77 to help me hide those specific items maybe files, directories, or registries that are random in names.

I could hide "myprocess" via "test console", I was soooo happy! thereafter, i reboot the OS and found "myprocess", which was hidden before rebooting, now appeared again! I tried to write the PID into the registry under $77**, but it didn't work, because processID kept changing every reboot.

And also, I would like to hide some of my specified files and directories, I didn't know how to do it, because I couldn't find a place to input the names of files or names of directories.

So, I have to rename the files or directories that begin with "$77", they hid! but this also causes execution wrong for wrong names of files.

Hope these desired abilities be available soon.

Thank you guys anyway, the r77 is amazing!

bytecode77 commented 3 years ago

Thank you very much for your feedback & input and for opening this issue!

Hiding items by specific names was requested several times by now and is therefore one of the next items on the agenda. The plan is to have more keys under $77config to put in process executable names and full file paths for directories or files.

I can't say exactly, when this feature will be available, so please stay tuned for upcoming releases. Please make sure to check the changelog of the documentation to get an overview of new features, once a new version is available.

In the meantime: The currently preferred way to hide a process by ID is to write the PID every time this process starts. The r77 service does this by writing to $77config\pid\svc32 and svc64. It should be implemented in the process itself. If this is not possible, maybe another already running process ("master process") could do this. If this is also not an option, you would need to wait for the next release ;)

GV13057911485 commented 3 years ago

Really expect this feature and believe you will successfully turn it true.

bytecode77 commented 3 years ago

Version 1.1.0 is now released with two additional keys in the $77config key:

The paths key needs full paths to files, directories, junctions or named pipes. Example:

I hope this feature helps you and others who were looking forward to it :)

GV13057911485 commented 3 years ago

Hi bytecode77,

really happy to see your rapid response to a new awesome release. I had tested the current release, I can manage to hide any of my processes by configuration system. But I still can see those stealthy processes in another application tool named AIDDA64, is AIDDA64 low to RING0? can you please test it with it?

I also tested hiding filename/directory by manual config, they are working fine. I did another test by clicking a registry script to add specific paths to the config system in bulk, found nothing added, my script is as below. Do I need the higher privilege to merge these scripts?

-------------------------***--------------- Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\$77config\paths] "aaa"="c:\windows\system32\aaaService.exe" "bbb"="c:\windows\system32\bbbray.exe" "ccc"="C:\Users\Admin\AppData\Roaming\ccc" "testfolder"="C:\Users\Admin\Desktop\New folder" -------------------------***---------------

THANK YOU AGAIN!

bytecode77 commented 3 years ago

AIDA64 is indeed showing prefixed files, so I have added this on my ToDo list. It needs further analysis before I make any assumption about the cause, though.

Generally speaking, some modules require to hook one single function and they work with absolute certainty (e.g. hiding registry keys&values). But some information can be gathered in lots of different ways, that is CPU usage calculation in particular. It is a RE nightmare to analyze how certain task managers obtain CPU usage. That's why there are still some documented bugs that need to be addressed, too.

The above reg-file, however, seems to have missing a \ after $77config. One thing you can do is create this registry key in RegEdit and then export it. That way, you see the exact format and what may be missing.

GV13057911485 commented 3 years ago

I will try more and more scenes and will report what I find in this issue opened by myself. thank you very much for your nice job!

bytecode77 commented 3 years ago

After some RE, I have found that AIDA64 uses WMI to populate the process list. This is also why refreshing the list takes so long: WMI is just slow.

When injecting WmiPrvSE.exe, processes with the prefix are, indeed, hidden from AIDA64. But processes hidden by ID or name are not. Unfortunately WmiPrvSE.exe is running under the NETWORK SERVICE account, which cannot read the config system under HKEY_USERS.

This brings a very important issue to the surface: Currently, the config system is available under both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER (of all users) to make it writeable by any process. However, HKEY_USERS is just not readable by all processes, such as the WMI service.

The next release will address this by introducing an architectural change, where the config key will be available under HKEY_LOCAL_MACHINE\SOFTWARE\$77config exclusively. To ensure write access by unprivileged processes, this registry key's DACL will be set to be fully accessible by all users.


Even though the bug you reported is minor, it still brought a bigger issue to the surface. Thank you for your contribution and improving r77!


Edit: Version 1.2.0 is available. The change log mentions the architectural improvement of using HKEY_LOCAL_MACHINE\SOFTWARE\$77config exclusively and setting the DACL.

GV13057911485 commented 3 years ago

After some RE, I have found that AIDA64 uses WMI to populate the process list. This is also why refreshing the list takes so long: WMI is just slow.

When injecting WmiPrvSE.exe, processes with the prefix are, indeed, hidden from AIDA64. But processes hidden by ID or name are not. Unfortunately WmiPrvSE.exe is running under the NETWORK SERVICE account, which cannot read the config system under HKEY_USERS.

This brings a very important issue to the surface: Currently, the config system is available under both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER (of all users) to make it writeable by any process. However, HKEY_USERS is just not readable by all processes, such as the WMI service.

The next release will address this by introducing an architectural change, where the config key will be available under HKEY_LOCAL_MACHINE\SOFTWARE\$77config exclusively. To ensure write access by unprivileged processes, this registry key's DACL will be set to be fully accessible by all users.

Even though the bug you reported is minor, it still brought a bigger issue to the surface. Thank you for your contribution and improving r77!

Edit: Version 1.2.0 is available. The change log mentions the architectural improvement of using HKEY_LOCAL_MACHINE\SOFTWARE\$77config exclusively and setting the DACL.

You are a cool guy! Love sooooooo much!

GV13057911485 commented 3 years ago

I had double-tested V1.2.0 for processing hidden under AIDDA64, it works perfectly!

now I had two more wishes, one is already on the owner's to-do list, that is hiding any registry as I want. The other wish is Hoping a "customized prefix" for replacing "$77", when we click "installer.exe", r77 pops up a box informs the user to "input your prefer prefix", this brings more stealthy operations, expect this feature so much!

Regards!

bytecode77 commented 3 years ago

Registry key/value hiding by specified path: What is your intention behind this? The reason I ask is that registry access can have a drastic performance impact, when overdoing it in the hooked function. That's why I didn't implement it at the moment. If, for example, you are trying to hide a user from the OS, keep in mind that there are various ways to get a list of Windows users. It all depends on the specific use case. Some information, such as this are just not that easy to fully hide by just masquarading the file system and the registry. But the best approach really depends on your ultimate goal.

The prefix "$77" is static and usually isn't required to be changeable in run-time. There is a constant in r77api.h and its analogue GlobalAssemblyInfo.cs. If you change both and re-compile, you have a new r77 build with a different prefix.

The installer, however, is not designed to show dialogs - it is a silent and instant installation to be deployed alongside your primary application. That application can be used to write into the configuration system.

GV13057911485 commented 3 years ago

Failure Report: Today I tested again and found the r77 hook was removed after reboot, all the hidden items appeared in the task manager.

OS: windows 10 Home N x64 Version: 10.0.19042 n/A Build 19042

Thanks!

bytecode77 commented 3 years ago

Was it removed from the system - i.e. it never started again? Or did it fail to start in one particular instance?

GV13057911485 commented 3 years ago

Was it removed from the system - i.e. it never started again? Or did it fail to start in one particular instance?

Before reboot, I installed the hook without problem, also merged the registry to hide those process, service, and file folders, everything was fine.

Then I reboot the system to see if everything keep fine just like what I tested in windows 7. Unfortunately, I found the CPU occupied up to 90%, seems the defender was working busily to remove the hook. about 5 minutes, the hook was clear and the process, service, files appeared.

bytecode77 commented 3 years ago

Does the service start normally when you reboot the machine once again? I would like to triage what kind of bug this is. If the service starts after another reboot, then we have an issue, where the RunPE based initialization sporadically fails. If it doesn't start at all, then it was detected. Currently, however, Defender does not detect r77. Also, AV is very busy ocasionally, not necessairly because of the hooks. So, which one is it?

GV13057911485 commented 3 years ago

When I saw your question, I tested again. The r77 service didn't start normally when the system restart, because the defender (real-time protector) started immiediatly after reboot (it was manual off before reboot), then defender removed the "install.exe" and clean the hook, I saw the $77blackhat once I saw the windows desktop.

bytecode77 commented 3 years ago

Okay that's new info. Usually, Defender does detect Install.exe, which is why I strongly recommend to run it using RunPE and never drop the installer on the disk. However, after installation, Windows Defender didn't detect the running processes and also didn't remove any hooks on my machine. Maybe it's detecting it now, but I will need to check on this. I will let you know when I know more, but I can't make any promises on when I get to analyze and fix it.

GV13057911485 commented 3 years ago

Thank you for your fast respond. yes, usually defender didn't detect installed hooks before, that really made me happy. but now, win10 defender samplized the hooks and start to remove it however Win 7 I tested still fine.

bytecode77 commented 3 years ago

Another issue was opened (#10) indicating the same problem: The execution of Powershell with the particular command line is blocked by Windows Defender.

I will investigate it and once I have managed to evade Windows Defender detection, I will release a fix and close issue #10