Mortar Loader not detected

[NewbyUser 72]

Is there any truth to this?

[itman 1,659]

Here's the Github reference: https://github.com/0xsp-SRD/mortar

Most Interesting:

Quote

The mortar technique is an encryption and decryption mechanism for malicious binary using the fly blowfish encryption/ decryption stream. Blowfish is a cipher based on blocks (64 bits) that also uses symmetric keys (both encryption and decryption). In addition, blowfish is based on a Feistel Network(A Feistel iterates a specific function a certain number of times, and each cycle is called around).

Test Cases

Starting with ESET, internet security was effortless and didn't take a while to run the PE inside the memory without detection; I am not here saying that ESET is good or bad; I am just indicating that ESET becomes blind while dealing with malware execution in memory blocks.

https://0xsp.com/security research & development (SRD)/defeat-the-castle-bypass-av-advanced-xdr-solutions

-EDIT- I also wouldn't get too upset about Eset not detecting this bypass. As the author notes:

Quote

Standing by the previous results, I conclude that All AV solutions are the same, and by using this technique, it is possible to achieve a bypass either by EXE or DLL loader.

Edited December 21, 2021 by itman

[NewbyUser 72]

2 hours ago, itman said:

 

-EDIT- I also wouldn't get too upset about Eset not detecting this bypass. As the author notes:

Not upset at all, it's part of the cat and mouse game. Eset and the Big K will figure it out I'm sure.

Although it is slightly concerning it was "easy" to bypass Eset;

"Starting with ESET, internet security was effortless and didn't take a while to run the PE inside the memory without detection; I am not here saying that ESET is good or bad; I am just indicating that ESET becomes blind while dealing with malware execution in memory blocks."

And it was challenging to get around K. I generally consider them equals

"Moving our test into Kaspersky was challenging, but at the end of testing, I was able to bypass and lunch a complete act of compromise, including loading Mimikatz,cobalt strike"

Edited December 21, 2021 by NewbyUser

[peteyt 393]

I'd be interested to see if anyone from Eset has a response @Marcos I.e. any signatures to stop this and anything eset can do to help prevent this method in the future?

[itman 1,659]

37 minutes ago, peteyt said:

I.e. any signatures to stop this and anything eset can do to help prevent this method in the future?

The problem is not having a signature for the malware being deployed. The problem is detecting that the malware exists:

Quote

I made a file containing the following payload tag string "lawlaw" to demonstrate straightforward proof of concept. (the PoC is not valid EXE). After toggling a breakpoint into the first procedure when loading the encrypted file into the string memory, the following lea instruction has been used to load the effective address of encrypted input data in the Assigned address in ESP/RSP.

After that, the loader will start decrypting the encrypted data inside the memory stream with the valid decryption key.

Later on, since this output format is base64, it becomes challenging for AV to detect and isolate the malicious image. The technique will copy the malicious payload into another allocated memory address to make it harder.

Edited December 22, 2021 by itman

[NewbyUser 72]

29 minutes ago, itman said:

The problem is not having a signature for the malware being deployed. The problem is detecting that the malware exists:

I thought Eset had excellent memory scanning capabilities.

[Peter Randziak 1,130]

Hello guys,

thank you for sharing, our research teams are already on it.

Peter

[itman 1,659]

14 hours ago, itman said:

After that, the loader will start decrypting the encrypted data inside the memory stream with the valid decryption key.

Later on, since this output format is base64, it becomes challenging for AV to detect and isolate the malicious image.

The problem is that Base64 is a binary-to-text encoding method while not an encryption scheme per se, does make a data stream indecipherable:

Quote

Here is a well-known idiom from distributed computing:

Many hands make light work.

When the quote is encoded into Base64, it is represented as a byte sequence of 8-bit-padded ASCII characters encoded in MIME's Base64 scheme as follows (newlines and white spaces may be present anywhere but are to be ignored on decoding):

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

 

https://en.wikipedia.org/wiki/Base64

Since Base64 is used extensively on the web, the challenge is to identify when it is being used maliciously. Then to only decode those instances prior to execution.

Edited December 22, 2021 by itman

[itman 1,659]

I will also state this.

Eset has the capability to detect this POC activity. I have seen it set its deep behavior monitoring hook into dllhost.exe. The problem is that it currently only does so when it detects suspicious activity originating from a dllhost.exe instance. It needs to start monitoring rundll32.exe instances by default.

-EDIT- I stand corrected. Eset is monitoring rundll32.exe:

Then there is the question if LiveGuard detects the malicious .dll when dropped on a device? If it does, then LiveGuard needs to be included in every Eset consumer version!

Edited December 22, 2021 by itman

[itman 1,659]

I will also add that the malicious code hiding technique used in this POC is neither unique or new.

First:

Quote

After converting to base64 we are going to encrypt it using standard AES encryption and convert it again to string.

Brief explanation of the conversion:

• Convert your binary (bytes -> base64)
• Encrypt (base64 -> bytes)
• Convert it again (bytes -> base64)

 

Later:

Quote

The base64 string is the one that was created and saved in a file in the first step (our encoded encrypted malware).

Reverse process:

• Convert (base64 -> bytes)
• Decrypt (bytes -> base64)
• Convert it again: (base64 -> bytes)

After decrypting the payload we are going to execute it in memory, using memory injection in C#. This method is not new and you can learn more about it here.

 

https://medium.com/@carlosprincipal1/how-to-bypass-antivirus-av-2020-easy-method-69749892928b

 

Edited December 22, 2021 by itman

[NewbyUser 72]

1 hour ago, itman said:

I will also add that the malicious code hiding technique used in this POC is neither unique or new.

First:

Later:

https://medium.com/@carlosprincipal1/how-to-bypass-antivirus-av-2020-easy-method-69749892928b

 

Then why is it so easy to bypass Eset? Not very comforting 

[itman 1,659]

Here's another malware that has been "flying under the AV detection radar" for 3 months that is using rundll32.exe: https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign#:~:text=We have created a YARA rule to identify this BLISTER activity .

[Peter Randziak 1,130]

On 12/22/2021 at 11:48 PM, itman said:

I will also add that the malicious code hiding technique used in this POC is neither unique or new.

First:

Quote

After converting to base64 we are going to encrypt it using standard AES encryption and convert it again to string.

Brief explanation of the conversion:

• Convert your binary (bytes -> base64)
• Encrypt (base64 -> bytes)
• Convert it again (bytes -> base64)

 

Expand  

Later:

Quote

The base64 string is the one that was created and saved in a file in the first step (our encoded encrypted malware).

Reverse process:

• Convert (base64 -> bytes)
• Decrypt (bytes -> base64)
• Convert it again: (base64 -> bytes)

After decrypting the payload we are going to execute it in memory, using memory injection in C#. This method is not new and you can learn more about it here.

 

Expand  

https://medium.com/@carlosprincipal1/how-to-bypass-antivirus-av-2020-easy-method-69749892928b

 

On 12/24/2021 at 4:45 PM, itman said:

Here's another malware that has been "flying under the AV detection radar" for 3 months that is using rundll32.exe: https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign#:~:text=We have created a YARA rule to identify this BLISTER activity .

Thank you for sharing those, I'm checking it with the guys responsible.

Peter (CCDBL-2023, CCDBL-2024)

[itman 1,659]

7 hours ago, Peter Randziak said:

 

Thank you for sharing those, I'm checking it with the guys responsible.

Peter (CCDBL-2023, CCDBL-2024)

Peter,

When I checked on VT a couple of days ago in regards to Blister malware, Eset was detecting at least one binary in each IOC category listed in the Elastic article. As such, I believe detection for this malware is no longer an issue for Eset.

Would appreciate feedback on Eset detection of technique used by Mortar Loader.

Edited January 4, 2022 by itman

[Peter Randziak 1,130]

On 1/4/2022 at 5:45 PM, itman said:

Would appreciate feedback on Eset detection of technique used by Mortar Loader.

It is being worked on and multiple improvements and fixes will be implemented...

Peter (PCDHIPS-581)

[itman 1,659]

3 hours ago, Peter Randziak said:

It is being worked on and multiple improvements and fixes will be implemented...

Fortinet detects its process hollowing activities: https://www.fortiguard.com/threat-signal-report/4357 . This is one way to get around the more troublesome activities Mortar Loader performs.

Eset HIPS is excellent at detecting process hollowing via a process modification rule based on my prior testing. The problem is Eset would have to be monitoring every non-protected; e.g. PPL, process to accomplish this. However, a "tell tale" sign of process hollowing is process suspension.

[itman 1,659]

Also of question is if Fotigate would detect if process hollowing was not deployed via cmd.exe? Per the 0xsp.com article posted at the beginning of this thread:

Quote

So at this point, instead of performing process hollowing to CMD.exe process, I have performed into the primary process of XDR and recompiled the whole loader as DLL.

after doing that, XDR prevented the attack again, so the final thing I do is by scripting a bat file that can perform the attack as one-click execution.

@echo off

cmd.exe /c loader.dll,stealth

in summary, when we click on the bat file, it will execute rundll32.exe to run the loader and load the encrypted binary and execute it inside the memory

Edited January 7, 2022 by itman

[itman 1,659]

As far as deploying the Mortar Loader .dll version, I would opt for the recently discovered undocumented way of doing so:

Quote

Grzegorz Tworek has now noticed that there is an undocumented possibility, over which theoretically arbitrary file systems can be used when formatting. Only an appropriate DLL must be present, which takes over the formatting. As parameter for /FS then the name of this DLL with a prefix U is to be indicated. A command line of the type:

format I: /fs:UMyDll.dll

would then load the library file MyDll.dll and cause it to be listed. This DLL is then executed in the search path, i.e. the program folder and other folders. Grzegorz Tworek has demonstrated this on his own DLL called Pwning.dll, which then displays a message box with the word Pwned! There are certainly a few ways in which this can be abused.

https://twitter.com/i/web/status/1477925112561209344