One question Bytecode77! ^- ^

[fSociety-Protected]

Is it possible to inject the Rootkit with C# natively or in some other way, without using PowerShell?
I say this, because the injection with PowerShell, is detected by many AV's. :://

[bytecode77]

Powershell basically executes InstallStager.exe (.NET) using Assembly.EntryPoint.Invoke. That's the reason why this is the only executable, written in C# - to make it executable from Powershell.

So you have two options:
1.) Perform Assembly.EntryPoint.Invoke on InstallStager.exe and put InstallStager.exe into the .NET resources of your project

or 2.) Copy the entire code of the InstallStager C# project into your project. Rename the main method to somethink like "StartR77Service" and call this method. It will create both r77 native service processes using RunPE.

Just keep in mind that elevated privileges are needed for the r77 service to start. As described in the documentation, a rootkit that only injects non-elevated processes would not give you any benefit. Since you're using r77, I'm guessing that your product has elevated privileges at least once to install r77.

[bytecode77]

I would still re-open this issue, as it points out that Windows Defender is detecting execution of Powershell with this specific command line. This problem has been raised in issue #9 as well and needs further investigation.

I will close this issue, once I have managed to evade AV detection of the startup routine,

[fSociety-Protected]

Well yes, in my case, I use as AV, NOD32, I'm using as a stealth module for my project, a modified version of your Rootkit r77(Which is awesome!), and the truth, everything works as you would expect, but when you install the R77, NOD32 detects the rootkit injection as malware, specifically as a trojan.

That yes, even being detected in Runetime, the Rootkit ends up installing without any problem.

Anyway, I'm still investigating the options you told me and if I find any other way I'll comment it here! ^- ^

[fSociety-Protected]

Ohh, you gonna update r77 ?
You found a solution to ByPass every AV ?

[fSociety-Protected]

I have a "fix solution" but its not a Bypass, its like an AV killer, maybe, so.... 😅😅

[bytecode77]

I was just going through the open issues yesterday. I left this one open, as I have found out Windows Defender might be blocking the startup of r77. Yesterday I finally got the time to investigate it, but then it was not blocked by Defender.

So apparently, it's blocked by NOD32, is that correct? Is the execution of Install.exe from disk blocked by your AV, or is the Powershell startup routine blocked? Because if Install.exe is blocked at scantime, you would need to RunPE the installer. Since you implement the installation routine directly in your project, I'm guessing you mean the Powershell startup is blocked.

Could you share your experience with AV? It's hard to test r77 with all of the AV's, that's why feedback is very welcome :) And of course, if the Powershell startup is blocked, that is indeed in scope of r77. If it's just the installer executable, then RunPE is the solution.

[fSociety-Protected]

Actually, r77 its detected at runetime by NOD32, I dont know if another AV block r77 startup or not, but when I scan the install.exe on AntiScan.me r77 its detected by some AV...

Im sure, this is fault to RAT Venom Software, who use the r77 to hide the startup payload in the victim machine.

At this moment, I have a "temporally solution" with Windows Defender.

With this command implemented in my project, I can disable Windows Defender to execute a clean Installation of r77 :

"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All Set-MpPreference -DisableIOAVProtection $true

When the rootkit is sucessfully installed, I just enable again WD.

I am working right now, in a project, to deactivate any AV in the market.

I said KILL, NOT BYPASS....

But well, right now I'm also doing several things in my life, (studies, work, etc...) and my time is not pressing.

When I have more news, I will update the post, but for the moment this is all the news I have.

I have been trying to integrate in RunPE the r77 to my project, but I do not know if it is because it includes Costura.Cody to assemble all the .DLL inside my project or that... I have not been able to make that it functions, for the moment.

[bytecode77]

Me, too. I have job, wife, friends, obligations, etc... That's why I sometimes need a few days or weeks to reply on a thread, etc...

Killing AV seems like a working approach. Just keep in mind there are two ways that r77 is detected and blocked by AV:

At scantime, Install.exe is detected and execution is blocked

For this, the only viable approach would be storing an encrypted version of Install.exe, decrypting it in memory and using RunPE to create a process of it. Note, that this executable is 32-bit and the process that runs it using RunPE must be 32-bit, too. Internally, r77 uses RunPE and reflective DLL loading, to avoid any files on the disk, since this is a sure fire way to get detected and removed.

Alternatively, replicating the installer's logic in your code like you did is a very nice approach, too.

At runtime, the Powershell commandline or DLL injection is blocked

If this happens, then I need implement some precautions to avoid it. It doesn't happen with Windows Defender. Defender only detects Install.exe at scantime. If this happens with NOD32, please let me know and I'll try to figure something out.

[fSociety-Protected]

Yes, yes, r77 its several detected by NOD32 when Install.exe execute the InstallStager part.

The rootkit semms working anyways, but get detected too. 😌

[bytecode77]

I have installed NOD32 in a VM and it does block the stager that's supposed to RunPE both instances of the r77 service. Since AV evasion is always a daunting task, I can't tell exactly when there will be a bugfix, But it's number 1 priority for r77 and I'll post back once I've figured out how to evade detection.

[fSociety-Protected]

Very well, I am very busy right now with other projects, when I resume work with r77, I will try to find a solution.

As long as I can come up with a solution for AV's evasion, but keep in mind, that thanks to the remote administration tool "VENOM" (the old version), r77 is detected by most AV's (you can check it by uploading the "*.DLL" or the "Install.EXE" of r77 to http://www.antiscan.me/).

The only experiences that I have been able to verify by myself about the detection of r77, have been with Windows Defender and NOD32.

Well, I hope that together we can find a possible solution to the detection issue. ^- ^

[bytecode77]

Me, too. I'm also very busy most of the time and therefore it can sometimes take a while before I respond or actually get to fix issues. I was working on r77 for about 3-4 months before I released version 1.0.0. And I really appreciate any contribution from you, the community, that helps in improving my projects :) Particularly AV evasion is a complicated task.

I just checked out "VENOM" - and it seems like they're using the old 0.6.0 version of the rootkit. This version is a very early beta that did not even work properly in x86 and it only hides processes and files. This rat also drops the DLL's to disk and uses LoadAppInit_DLLs to inject the rootkit. This by the way is not compatible with secure boot enabled. That's why I've put so much effort into implementing reflective DLL loading to make it 100% fileless. "LoadAppInit_DLLs" is simply no longer useful.

My rootkit stands out by the fact that it's both fileless and handles installation all by itself and out-of-the-box. I will do what it takes to keep improving it and making it FUD.

[bytecode77]

Yesterday, NOD32 trial activation didn't work in my VM. Today I took another test run. This is what I've noticed so far:

• The DLL files are considered clean by most AV's. The installer has a high detection rate.
• NOD32 detects the powershell process as MSIL injector and terminates it. That's why the rootkit doesn't initialize.
• When manually starting the scheduled tasks from the task scheduler, the rootkit properly initializes.
• Injecting the rootkit to processes using the Test Console is not recognized by NOD32 either.
• Windows Defender does currently not seem to detect the rootkit once it is installed (at least on my VM)

Funny ambiguous detection... It seems like the only weak spot is the powershell initializer that gets detected. If this is really the case, then that's a fortunate discovery and I'll try to figure out a way to change it so that it doesn't get detected.

[fSociety-Protected]

Yes, as I told you some time ago, the problem lies in the initialization of the rootkit using Powershell.

That's why, when I opened the post, I asked you if it could be initialized using C#/C++ and thus avoid the use of Powershell. 🙃🙃

[bytecode77]

Since r77 is fileless, it must be some file that is part of the operating system to initialize the rootkit. Powershell is excellent, because it can load C# executables from registry and invoke them. At the very minimum, some OS executable must be able to perform a RunPE. The alternative is to drop exe files, which would not be fileless anymore.

I'm currently also working on a new version of my crypter where I've done some research on anti emulation techniques. This is an excerpt of the emulation detection:

proc DetectEmulator
	; Allocating 100 MB of memory must work
	invoke	HeapAlloc, [ProcessHeap], HEAP_ZERO_MEMORY, 100 * 1024 * 1024
	test	eax, eax
	jz		.emulator

	push	eax
	mov		edi, eax
	mov		ecx, 100 * 1024 * 1024
	cld
	rep		stosb
	pop		eax

	invoke	HeapFree, [ProcessHeap], 0, eax

	; SetErrorMode return value must match previous value
	invoke	SetErrorMode, 1024
	invoke	SetErrorMode, 0
	cmp		eax, 1024
	jne		.emulator

	; VirtualAllocExNuma must work correctly
	invoke	VirtualAllocExNuma, -1, NULL, 1000, MEM_RESERVE or MEM_COMMIT, PAGE_EXECUTE_READWRITE, 0
	test	eax, eax
	jz		.emulator

	xor		eax, eax
	ret
.emulator:
	invoke	ExitProcess, 0
endp

The first method seems to be very effective, even though it's 5 years old. I've done lots of tests, where I drop EICAR only and test single emulation detection routines seperately. I can confirm that the above methods work (May 2021).

C#

byte[] mem = new byte[1024 * 1024 * 200];
for (int i = 0; i < mem.Length; i++)
{
	mem[i] = 123;
}

This is something that an emulator typically can't handle. Could you try to add this to the very beginning of the Main method (before Process.EnterDebugMode) and test, whether NOD32 is still blocking powershell? I've tested it and it seems to be enough to evade emulation of the stager. If you also confirm that it's working, I will push a new release.

[fSociety-Protected]

Ohh, looks like a VERY INTERESTING proposal, I'm not at home right now, I'm away on a trip, this weekend I'll try to take a look at it, see if this solves the InstallStager detection!

PS : You are awesome, how can you find time for everything ?? 😜

[bytecode77]

Hold on for a second... I have done additional testing. It seems like NOD32 occasionally slips detection, but anti emulation techniques in the stager still not make the startup undetectable.

The problem is actually AMSI. This interface sends InstallStager.exe to the AV before Powershell executes it. This is because Powershell (and other scripting utilities) implement AMSI. This way, AV gets visibility into script based attacks, which could otherwise not be detected.

So, the new goal is to bypass AMSI before the payload is read from the registry and executed using EntryPoint.Invoke(). This is a lot more tricky than I originally thought. Plus, I can't tell whether NOD32 is detecting the file through the AMSI interface, or whether it's the memory scanner. Since running the scheduled tasks manually is not detected, I guess the ultimate goal is to disable AMSI in the Powershell commandline prior to loading the stager executable.

I'll keep working on figuring this out. Any community input from anybody reading this is greatly appreciated!

[fSociety-Protected]

Ohh, I see, so AMSI is the problem?

I will look for more information on this, and investigate possible ways to disable AMSI from Powershell. 🤔🤞

[bytecode77]

AMSI is not the problem with NOD32 in particular, but rather the HIPS. It's detecting the api call sequence of the RunPE in the stager, which is what gets r77 caught.

These are the changes I have made so far:

• AMSI bypass for the powershell script (known technique, but custom implementation). It will not change anything for NOD32, but AV's no longer receive the C# stager binary through Powershell AMSI.
• Unhook ntdll.dll in both the stager and the r77 service. NOD32 hooks a lot of functions, such as NtWriteVirtualMemory, etc... You can see it in a debugger - there is a jmp instruction at the beginning of many ntdll functions.

These changes are currently only on the dev-Branch. You can compile yourself and preview them, if you want. Currently, NOD32 no longer removes r77 from the system, but still detects it and in turn reboots the VM. From this point forward, my VM is stuck in a rebooting-cycle.

I'm gonna have to figure out why NOD32 lets r77 initialize and take over the system, but still detects it.

[fSociety-Protected]

Yes, the truth is that very strange that it detects it, but still, r77 work normally? 🤔
Maybe, NOD32, is linked to a function that triggers NOD32 alarms? 💭

Currently RunPE is the best way to initialize the stager, but couldn't some morphosis system be used ?
I think you yourself created a project from an .exe that auto-morphed every time it was run.

Maybe combining the r77 with the auto-morph project would make it more invisible to AV's. idk.

[bytecode77]

r77 1.2.1 is available.

As of now, r77 is no longer detected or removed by NOD32. Several AV/EDR bypass techniques have been implemented. Check out the changelog and section 4.5 AV Evasion Techniques.

Note: If you integrate r77 by invoking Install.exe using process hollowing, you need to perform DLL unhooking as described in the documentation.

r77 should now run peacefully along with NOD32 installed. Please confirm and close the issue, if this is the case.

And thank you very much for bringing this to my attention! Typically, too many times, GitHub issues revolve around users requiring help with the usage of tools. However, your issue brought a really important topic to the surface that required fixing and brought improvement to the project.

[fSociety-Protected]

WoW ! I'm sorry I couldn't answer you or reply, but I've been without internet for a week :///
You see, I have one of the best companies contracted in Spain (1Gbps Simetric) and still, it goes terrible. 👎

Well, I'm going to try the new version, to see if I find any bug together with NOD32 ! ^- ^

I appreciate your attention and that you are a developer so attentive to his projects and with encouragement to continue to evolve !
I am doing a project that consists of an improved and adapted version of your current r77, that in a future I may release it, that day, I will remember your good faith in the attention received and I will proceed to send you a personal [LIFETIME] key for you brother. ;)

Do you have a contact email that you can pass me ?
# So I can pass you information about the project, now I have it paused, I have many exams, etc... but my intention is to finish it soon.
Well, I leave you mine : fS.xxxxxxxxx@pm.me

PS: Thanks again man!
You are fucking awesome bro, keep it up!

EDIT

Now works perfectly with NOD32! ❤️‍🔥

[fSociety-Protected]

[ ·> NEW ISSUE / DETECTION WITH NOD32 <· ]

---

NOD32 Updated to trigger the entire injection of Install.exe { r77 }
I thought that r77, would be undetectable for NOD32, but apparently, now NOD32 is back on the attack with a new detection system for injectors. Saddly.... (T- T*)

Some details :

Video Proof : https://screenrec.com/share/ZCq3uLovFY
AntiScan.me Proof : https://antiscan.me/scan/new/result?id=yQkIWPNqH5tN

[bytecode77]

I can confirm that NOD32 has updated detection routines for runtime detection and I'll have a look at it. However, fixing a detection will never fix it permanentaly, because this is a public release. I'll still look into it, but I can't tell how long it will take, nor how much time I have to analyze (it depends...)

---

However, what you are demonstrating in your video is that the file Install.exe is detected at scan-time. This is usually always the case. Scantime detection is a thing that can be avoided by correctly initializing the rootkit as described in the documentation in section 5 Integration Best Practices. It is very important that you decrypt Install.exe at runtime and execute it using RunPE. As mentioned in the docs, there is RunPE code in C# that you can use. Alternatively, if your main program is written in C++, there is a lot of example code online to use.

Also make sure to read section 4.5.2 DLL Unhooking. Because NOD32 hooks ntdll.dll, it is not possible to perform RunPE prior to unhooking ntdll. There is a function called UnhookDll() written in both C# and C++ that you can use for your main program.

So, what you should definitely do as a baseline is:

1. Store Install.exe in your resources encrypted. Do not use a 1-byte XOR key, because there are plenty of YARA rules just for that.
2. Never write it to the disk. What you've shown in your video is what will happen when you write the file to disk.
3. Unhook ntdll using my code prior to RunPE

It won't fix the current issue, but it is really important that you implement the deployment of Install.exe like this, because writing it on the disk will always get detected.

[fSociety-Protected]

I understand bytecode77, I am going to look at your documentation points [ 5 - 5.1 - 5.2 & 4.5.2 ] ^- ^
- I will try to implement it this way or similar in my project to see if I can get around any AV.

Anyway, yes, what you say is completely true, being a public version, it's complicated to keep a project of this size completely FUD, it's normal, anyway you are amazing, the attention, understanding and dedication you have, I haven't seen before in any developer. You are awesome! ❤️‍🔥