Crypter Fud Github

[Marlys Stotesberry]

Our crypter will prevent signature based detection and also mostly heuristic detection of AVs.At the end I will offer some tips to prevent dynamic analysis and also make it a little harder for reverse engineers and security researchers.The main task of our crypter is to obfuscate an executable through encryption and thereby bypass the signature-based detection of AVs. To ensure this, the decrypted code must must be executed in memory so that it never touches the hard disk.

the crypter holds our hardcoded stub we programmed before (as a template) and writes it to disk. Then it reads the PE file we want to obfuscate and inserts it in encrypted form as a resource into our stub.

We start with the stub. first we create a function to find the encrypted resource. This is the file which will be attached later by our crypter. The first two parameters the function expects is the resource name and the resource type to find the code.

I decided to use a process hollowing technique which is a bit easier to implement.We create a new process in suspended mode in which we can inject the code and then run it.The important things we do here are:

Now we have to write our crypter. Our crypter is also a CLI application so we read our input PE (the file we want to encrypt) as argument.We also create a byte array as a placeholder for the raw code of our compiled stub.We change this at the end otherwise our IDE will lag or be functionally compromised because the byte array will be very large.

Now we have to add the encrypted data as resource to our stub. For this we use BeginUpdateResource, UpdateResource and EndUpdateResource. As I mentioned before we have to make sure that we use the same resource name and resource type as in the stub. Otherwise our stub program will not find a resource to work with.

Adversaries love using free or cheap RATs or stealers, and I see a lot of RATs such as AsyncRAT during my daily malware analysis tasks. In this detection I want to examine a fairly recent sample from in MalwareBazaar that involves Snip3 crypter and DcRAT, an AsyncRAT clone. If you want to follow along at home, the sample is available here in MalwareBazaar:

This chunk of code defines some of the overhead boilerplate code involved with the Snip3 crypter. The $RUNPE variable contains decimal-encoded, gzip-compressed chunk of C# code. The INSTALL() function writes a bare minimum bit of code to disk to execute this downloaded code in the future. The Decompress() function inflates the compression on $RUNPE later down the line to make it usable. The second chunk of the script contains loads of additional boilerplate code from Snip3 designed to compile the RunPE code in memory, make the bare minimum of evidence on disk, and then load the generated RunPE assembly into memory.

Some of the structure and variable names reference Windows API methods used during process hollowing injection. These include WriteProcessMemory, ZwUnmapViewOfSection, and CreateProcessA. While the structure and variable names are self-explanatory, the process of those names getting attached to the actual API calls is slightly more obfuscated. This can be seen in Helper struct. Each of the API calls and DLL names required are stored as an integer array that must be decoded in a later function.

The API mapping to structure name process is handled by code from this NativeMethods class in the crypter. During the mapping process the class calls Decode.BytesToString() in another class to finish translating each integer array to a string needed for the API.

The chunk of code above writes a timeout and deletion command to a Batch script file and then executes it. This is usually a self-deletion measure for RATs and stealers. If obfuscation was involved in this sample, very little of the code above would be readable. The strings would likely be scrambled as would the variable names. In some cases of obfuscation, adversaries may even try to use non-English Unicode characters to make the code unreadable.

Command and control (C2) frameworks often support multiple platforms, and PowerShell Empire is no different. In older days, there was a Python Empyre version that eventually merged into the full Em...

Glad you asked. Ezuri is a small Go crypter that uses AES to encrypt a given file and merges it with a stub that will decrypt and execute the file from memory (using the previously mentioned memfd_create syscall). My original goal was to write it in Assembly but that would require more time so it is a task for the future.

It will also do some basic tricks during the process execution, making it a little bit harder to be detected by an inexperienced eye. The main trick consists on daemonizing the process, detaching it from a tty, having it to run in the background (and as I said, from memory). If you are not familiar with daemons, you can find more information here.

The stub will be compiled during the crypter execution. After you enter your desired parameters like below: $ ./ezuri[?] Path of file to be encrypted: demon[?] Path of output (encrypted) file: cryptedDemon[?] Name of the target process: DEMON[?] Encryption key (32 bits - random if empty):[?] Encryption IV (16 bits - random if empty):[!] Random encryption key (used in stub): R@7ya3fo1#y67rCtNOYwpm5lyOA5xeYY[!] Random encryption IV (used in stub): 5Ti65dgBKidm5%sA[!] Generating stub...

The crypter-as-a-service model is indicative of the trend toward malware authors creating and selling code to other groups with less technical sophistication. As a result, more financially motivated threat actors can adopt better attacks if they have the money to spend. This results in many groups putting forward the bare-minimum effort required to execute sophisticated malware campaigns.

Our description of the attack chain flow follows the artifacts that are known to us. Although the initial access infection vector is missing, we have identified cases in which a VBS code is executed that leads to an .hta file execution described as Encoding.txt. The next stages involve persistence and AV evasion through PowerShell, and then the final stage consists of a standard .Net reflective loader which loads the RAT of choice. Along the way, the actors and the author use free accessible code and file sharing services such as github.com, cdn.discordapp.com, and minpic.de.

Within all of its versions, the crypter maintains the same execution flow with different code tweaks in an attempt to avoid detection by AV. The above diagram covers the main Crypter functionality for several versions that we have observed since Jan 2021.

The loader and payload are hard-coded in this stage within a byte array variable, while each version saves it in a different format and names the variable differently (i.e $H1, $nam2021, $brazi). We have observed that those byte arrays contain PE files embedded in Hex, Decimal, or Base64 formats and sometimes also with character swapping as a simple encoding.

This is a .NET DLL that is embedded by the crypter author. The execution is via the calling convention Namespace->Class>Method defined in Server.txt. We observed that the DLL is often obfuscated by a .NET Reactor or Babel obfuscator.

The final payload, chosen by the user, is eventually executed within the hollowed process memory. In our analysis we have mostly seen either ASyncRAT or LimeRAT, which often come from an open-source RAT platform originally available through the NYANxCAT Github repository ( -x-CAT)

As part of our research, we were able to correlate 3 different YouTube channels that are used to market the following crypter. They might not be owned by the author but the following IOCs correlate between them:

194.33.45[.]109
arieldon.linkpc[.]net
fat7e07.ddns[.]net
100k1.ddns[.]net
100k2.ddns[.]net
top.killwhenabusing1[.]xyz
clayroot2016.linkpc[.]net
remmyma.duckdns[.]org
Getpass.ddns[.]net

The shellcode, below just a small snippet, is embedded in the script and has its own function here renamed as RunPE, the whole body is hidden away thanks to the string obfuscation function uxharcuawtv.

Once enumerated the exported functions from kernel32.dll and ntdll.dll, it becomes trivial to map the hash values found in the shellcode to their equivalent string versions - as seen at the beginning of the section.

Payloads are afterwards statically and dynamically fingerprinted. Dynamic checks are mandatory to overcome additional obfuscators or packers making static detection useless; the final results looks as follows.

Out of curiosity, analyzing the crypters of the administrator user, which also crafted the payload investigated at the beginning of the article, it shows how all three samples were - most probably - generated by the same (old?) CypherIT version.

CypherIT did not perform any game changer new techniques; also after peeling all obfuscation layers, it keeps under the hood the same features observed back in 2018, adding to the portfolio new tricks and functionalities (not fully outlined in the last section).

If the earlier versions of the specimen were storing the payload only in one section of the PE file, latest ones split and store it in multiple resources, but in essence, the rebuilding technique stays the same as before.

Recently, our team observed an incident involving our MS-SQL (Microsoft SQL) honeypot. It was targeted by an intrusion set leveraging brute-force tactics, aiming to deploy the Mallox ransomware via PureCrypter through several MS-SQL exploitation techniques.

Our investigation of Mallox samples led us to identify two affiliates with distinct modus operandi. The first focuses on exploiting vulnerable assets, while the second aims at broader compromises of information systems on a larger scale.

This blogpost report aims at presenting a comprehensive technical analysis of the techniques used to compromise the MS-SQL server we deployed. Additionally, it delves into the behaviour observed, with a focus on Mallox ransomware and its affiliates. Finally, we offer insights into detection opportunities to mitigate such threats in the future.

c80f0f1006