How to hide specific files, directories, registries as I want? about r77-rootkit HOT 18 CLOSED

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 ;)

from r77-rootkit.

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

• process_names for REG_SZ values with all process names to be hidden
• paths for REG_SZ values with full paths to be hidden.

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

• C:\path\to\file.txt
• \.\pipe\my_named_pipe

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

from r77-rootkit.

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.

from r77-rootkit.

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

from r77-rootkit.

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

from r77-rootkit.

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!

from r77-rootkit.

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!

from r77-rootkit.

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.

from r77-rootkit.

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!

from r77-rootkit.

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!

from r77-rootkit.

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.

from r77-rootkit.

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!

from r77-rootkit.

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

from r77-rootkit.

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.

from r77-rootkit.

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?

from r77-rootkit.

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.

from r77-rootkit.

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.

from r77-rootkit.

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.

from r77-rootkit.